Как рассчитать ресурсы веб проекта

Натрави на сервер, например, ApacheBench, увеличивая постепенно параметры нагрузки. Следи за выводом утилиты.

Да бери 8 ядер, 16 гигов оперативы.

https://www.bitrix24.com/self-hosted/performance.php

Но судя по этому высеру, эти криворукие обезьяны написали аналог киберпука на похапэ. Кеширование только средствами nginx сделай

Никак не рассчитать, всегда будет наступать такой момент, когда мало. Бери чучуть и будь готов покупать тачку пожырнее.

аналог киберпука

Аналог чего?

нашел на просторах интернет, что ядра подбираются 30%-60% от кол-ва воркеров за 10 минут. Если я правильно понял, то от кол-ва посетителей за 10 минут. Вот и думаю, это ж получается примерно 50 ядер. Ого а не жирно ль будет. Сейчас 16 ядер, 32 потока и как-то ж тянет, хоть и временами (в пик посещения) тупит.

нет. даже монструозное говно типа битрикса вывезет 50 запросов в секунду. Да тебе больше и не нужно. Количество процессов php-fpm только подсчитай, чтобы 100 клиентов не завалили сервак https://www.kinamo.be/en/support/faq/determining-the-correct-number-of-child-processes-for-php-fpm-on-nginx

А оно в cpu упирается в часы пик или куда? apcu всякие пробовали? Что говорит perf top в час пик?

аналог киберпука

Аналог чего?

Киберпука.

сделал скриншот htop, но не нашел как прикрепить его, поэтому делаю через ссылку. https://cloud.mail.ru/public/9izM/3hnrdLQbf/

прилагаю результат команды ps auxf https://cloud.mail.ru/public/nJ7H/Lt8Su2TCC

Задумался о веб кластере от 1с битрикс. Ну там разделить процесс на сервера App1, app2, memcached1, memcached2, mysql_master, mysql_slave. Блин ну опять же вопрос сколько отводить ресурсов (кол-во ядер и ОЗУ) для каждого сервера. Да и вообще есть ли смысл?

По cpu проблем не видно, проц загружен на половину от силы

Давай к нам, на serverless :)

Это что прикол такой? Полудохлый сайт на чмошнном битриксе грузит 32 ядра и сжирает 26 гигов оперативы? ДЛя этого высера криворуких макак нужон тридрипер?

Ну теперь понятно почему к вакансиям с битриксом тег хайлоад приделывают

Какие же вы дебилы.

Полудохлый сайт на чмошнном битриксе грузит 32 ядра и сжирает 26 гигов оперативы

Ну если крутить одновременно на одном инстансе nginx, apache и mysql то и не такое может быть.

так у меня такое же убогое говно как эти похапешные недофцмс и фреймворки - джанга крутится, жрет как в не себя… и по моим понятиям это ВСЕГО 2 гига. у меня больше всего жрет гитлаб (8 гигов), нгинкс, постгрес, редис и тд вообще - по сотне мегабайт. а проц грузится только во время сборок образов для докера. я уже не говорю про имеющийся оверхед в виде запуска всего через докер, а так же изнасилдование жестких дисков при сборках при каждом чихе. жопач не может столько сожрать.

f224dbdd6028   prod_api                                                                             0.08%     519.2MiB / 31.28GiB   1.62%     158kB / 47kB      0B / 51.2kB       10
845734cccb3e   prod_process_tasks                                                                   0.00%     95.52MiB / 31.28GiB   0.30%     8.58MB / 6.53MB   0B / 0B           1
68d75e5b7971   prod_websocket                                                                       0.03%     110.9MiB / 31.28GiB   0.35%     16.6MB / 21.9MB   123kB / 0B        3
949e3fa7ea17   celery_worker                                                                        0.32%     392.3MiB / 31.28GiB   1.22%     10.8MB / 11.4MB   0B / 0B           9
4439171a0e22   prod_client                                                                          0.00%     29.53MiB / 31.28GiB   0.09%     149kB / 2.48kB    0B / 12.3kB       22
270a1105bf1a   dev_client                                                                           0.00%     42.15MiB / 31.28GiB   0.13%     3.37MB / 15MB     213kB / 12.3kB    22
9e25ed61ceaa   dev_api                                                                              0.02%     662.9MiB / 31.28GiB   2.07%     11.5MB / 37.5MB   0B / 49.2kB       10
b51b67a6c147   dev_process_tasks                                                                    0.64%     102.3MiB / 31.28GiB   0.32%     61.2MB / 74.3MB   0B / 0B           1
ca8b59617d9a   dev_websocket                                                                        0.06%     133.5MiB / 31.28GiB   0.42%     1.42GB / 1.77GB   7.6MB / 0B        3
1753ce2a9c40   nginx                                                                                0.08%     39.79MiB / 31.28GiB   0.12%     1.82GB / 2.11GB   34.2MB / 26.6kB   6
9d6d67b6feb6   gitlab_runner                                                                        0.79%     25.03MiB / 31.28GiB   0.08%     18.4MB / 108MB    63.9MB / 0B       23
2d4a00c087e5   gitlab                                                                               11.52%    5.779GiB / 31.28GiB   18.47%    10.5GB / 177GB    680MB / 3.04GB    445
09d136e8d4bd   wordpress                                                                            0.00%     78.64MiB / 31.28GiB   0.25%     752MB / 235MB     125MB / 104kB     4
3f4ecf219752   redis                                                                                4.61%     27.88MiB / 31.28GiB   0.09%     176GB / 6.9GB     4.74MB / 1.93GB   6
8f74037e7ffb   pgadmin                                                                              0.03%     114.2MiB / 31.28GiB   0.36%     93.2kB / 0B       33.7MB / 9.81MB   5
26e847dae4d7   mysql                                                                                0.03%     95.3MiB / 31.28GiB    0.30%     55.3MB / 715MB    65MB / 17.9MB     8
3342ff4ee3d6   postgresql                                                                           1.22%     184.2MiB / 31.28GiB   0.58%     3.16GB / 7.03GB   132MB / 12.7GB    39
6ec96f7611e4   smtp                                                                                 0.03%     31.14MiB / 31.28GiB   0.10%     158kB / 65kB      30.9MB / 432kB    18
0f690d4da935   portainer                                                                            0.00%     19.88MiB / 31.28GiB   0.06%     98.3kB / 1.63kB   40.5MB / 810MB    16
28a2a2e7a9f5   deploy_currency-converter_1                                                          0.09%     408.5MiB / 31.28GiB   1.28%     668kB / 361kB     11.7MB / 590kB    25
4ef49258840f   watchtower                                                                           0.00%     16.63MiB / 31.28GiB   0.05%     0B / 0B           26.4MB / 0B       14
c69b62391305   runner-2eyw5dh3-project-21-concurrent-0-38f15715fa021015-docker-0-wait-for-service   0.02%     5.195MiB / 31.28GiB   0.02%     89MB / 30.9MB     0B / 0B           14
a223660ea161   runner-2eyw5dh3-project-21-concurrent-0-0a4d042b68a63433-docker-0-wait-for-service   0.00%     5.184MiB / 31.28GiB   0.02%     209MB / 93.4MB    0B / 0B           15
734940f9c48f   runner-2eyw5dh3-project-10-concurrent-0-5cb1784cd290e42d-docker-0-wait-for-service   0.02%     8.664MiB / 31.28GiB   0.03%     216MB / 100MB     262kB / 0B        14
fac52c77f8a1   runner-2eyw5dh3-project-21-concurrent-0-d07c6618f1c72586-docker-0-wait-for-service   0.03%     5.504MiB / 31.28GiB   0.02%     216MB / 101MB     541kB / 0B        14

Извиняюсь, поторопился с замерами. Залез сейчас и ахнул. https://cloud.mail.ru/public/rDyn/fsGzEiY8e Заметил что выросла виртуальная память для mysqld.pid . При этом кол-во mysqld.pid выросло с 50 до 269

Купи облако на Амазоне, слышал, что там ресурсы динамически добавляются по мере необходимости и нужно платить только за использованные. Точно не скажу, не пользовался.

Думал над этим, но это ж буржуи. Ни сегодня завтра перекроют кислород и все, приехали.

Да виртуальная память не так страшно. Скорее всего жирные файлы базы отображаются в память, вот Virt и пухнет. Вот то, что процессор по большей части нагружает MySQL настораживает. Посмотреть бы что там в process list, но это по сути уже в плоскость разработки переходит, а битрикс продукт коробочный, поэтому по сути с поставщиком нужно разговаривать об этом. И ещё одна гипотеза: не связаны ли во времени рост нагрузки и приход на сайт поисковых индексаторов или ещё каких роботов?

Понаблюдав, увидел, что как только кол-во посетителей за 10 минут начинает превышать 110, то running процессы начинают колебаться от 20 до 24. Из них примерно 19 mysqld (при чем каждый процесс отьедает 90%-100% отдельного ядра), 2 httpd, 1 php, 1 nginx

Подскажите плиз как рассчитать ресурсы (Кол-во ядер CPU, обьем ОЗУ) для интернет магазина.

В первую очередь оцени максимальное количество одновременно приходящих в магазин посетителей и максимальный создаваемый ими трафик и прими это всё за норму, на которой магазин должен работать без сбоев и существенных тормозов.

Киберпука.

Опередил! :)

Я имел в виду mysql-ный show processlist

Запустил, посмотрел. Немного не понятно, это что получается на каждый запрос отводится отдельное ядро? И каждый запрос - это отдельный running процесс mysqld? Просто раньше как-то об этом не задумывался.

Просто если так, то этот запрос

SELECT COUNT(DISTINCT BE.ID) as C FROM b_iblock B INNER JOIN b_lang L ON B.LID=L.LID

грузит ядра на 100%. Т.е. я смотрю, что отрабатывает 4 такие запроса и в это время 4 процесса mysqld грузят 4 ядра, каждое ядро на 99%-100%. Так и должно быть?

у меня больше всего жрет гитлаб (8 гигов)

Можно вопрос не по теме треда? Зачем этим куском дерьма кто-то пользуется вообще? У меня на рабстве тоже поставили гитлаб для CI трансляции вебпаком JS скриптов и CD в статичный хостинг — я могу лишь восхищаться бессмысленности и беспощадности сего действа.

Еще меньше относящийся к теме вопрос: зачем постгря и мускуль в контейнерах? Чтобы автоматически перезапускать после падения и накатывать новую версию сразу на двадцать хостах?

В свою очередь, я спешу пояснить по теме треда, что основная нагрузка в Bitrix24 ложится на сервер БД, потому что никакой логики работы с данными на уровне PHP нету — это классическая связка PHP+RDBMS, на которой индусы пишут сайты уже больше 20 лет. И будут писать. Проблема такой связки заключается в том, что отдельные операции на ней никогда не будут быстрыми, на любом железе. Например, какому-то эластику или кликхаузу для выполнения удобных им запросов по десяткам-сотням миллионов записей в БД нужны доли секунды. А для того, чтобы прошерстить по аналогичным запросам в мускуле данные фулсканом и/или сканом по нескольким индексам, нужны минуты, поскольку для него даже миллион записей в секунду является очень и очень хорошим темпом.

Зато на мускуле (постгре, оракле, ms sql) можно организовать довольно шустрое простое OLTP плана «добавить клиента», «обновить клиента», и узкие спектры запросов, под которые оптимизированы индекса и вообще структура таблиц. Именно эти запросы лучше всего выполняла System R в 70-х годах — с тех пор ее аналоги мало изменились по специфике производительности.

Мой опыт разработки системы под «любые запросы и любой режим работы» говорит о том, что классические РСУБД в принципе не могут с приемлимой производительностью вытянуть такой режим. А причина заключается в том, что ACID и близкие к нему гарантии очень и очень дорогие. А именно: гарантии сохранности данных завершенных транзакций при внезапном умирании сервера БД, которая требует кучу дисковых операций; быстрая атомарная публикация свежих данных, заставляющая транзакции сверяться друг с другом и постоянно ходить по бутылочным горлышкам; ну и вообще, табличное построчное представление данных в принципе не является универсальным — нынче нормой везде является наличие полнотекстового поиска, а табличное построчное представление категорически не умеет в полнотекстовый поиск. Самая главная и самая тонкая проблема заключается в том, что нормализованная табличная база данных ТРЕБУЕТ гарантий сохранности данных при умирании сервера и согласования изменений по бутылочным горлышкам, потому что иначе велик шанс получить безнадежно испорченную БД. А если вы базу денормализуете, то получаете конских размеров записи с кучей текста в них — и скорость фулскана десятки тысяч записей в секунду.

Единственное, что может посоветовать 1С-Битрикс своим клиентам в такой ситуации — это пихать все данные в оперативу, которой должно быть много, а в качестве энергонезависимого накопителя применять NVMe. На моем прошлом проекте пришли ровно к этому. Что эластик с кликхаузом работают на жестких дисках? Не, не слышали.

Купи облако на Амазоне, слышал, что там ресурсы динамически добавляются по мере необходимости и нужно платить только за использованные

Проблема амазона в том, что нагрузка на сервера при увеличении масштаба в среднем по больнице проекте растет не линейно, а быстрее линейности. Лох проектирует систему под AWS, мол «в этом месяце он нам обошелся в $20», а потом спустя год-другой с ужасом видит уже счет на $50'000 — но деваться уже некуда: либо полностью перерабатывать проект, либо продолжать платить амазону.

А что скажите по поводу яндекс облака?

А что скажите по поводу яндекс облака?

Да, можно и в яндекс облаке, и много где, но амазон — это вообще самый присамый дорогой хостинг. По крайней мере на более менее заметных нагрузках, значительно превышающих бесплатные лимиты. Сравни, например, $0.17/Гб исходящего трафика у амазона с 1 рубль/Гб у яндекса.

ну да. спасибо

Каждое подключение к базе это новый тред ОС. Запрос выполняется в рамках какого-то подключения, т.е. треда. Тред либо выполняется на каком то ядре либо спит ожидая каких-то данных(сеть, диск и прочее). Если запрос долго выполняется, то да это будет видно в htop как загруженное на 100% ядро процессора. Если запросов больше, то ядер будет занято больше. Этот конкретный запрос выглядит как будто вынимается из базы какой-то справочник. Если это так и он редко изменяется, то можно один раз его вынуть и положить в шаред мемори (apcu, redis, memcache) и тем самым разгрузить основную бд. Возможно в 1с битрикс предусмотрено какое-то кэширование данных в памяти и оно не включено?

Отвечаю: тот же postfix проще в контейнере поднять чем мучаться с его настройкой, с постгре и нгинксом у тебя может проблем и не будет… Смысл докера в том, что у тебя есть изолированное приложение в песочнице со всеми нужными либами для запуска, тебе не нужно сидеть ставить какие-то пакеты, настраивать все долго и томительно. Ты, например, на centos можешь использовать самые последние версии либ, интерпретаторов, компиляторов и тп, не боясь конфликтов. С gitlab’ом: он образы по коммитам собирает, а watchtower когда видит, что появился новый образ, собирает контейнер с последней версией приложения, останавливает текущий, запускает новый. Мне вручную ничего делать не нужно. Чтобы прочуствовать разницу нужно поднять все это говно вручную, а потом с помощью докера. С докером ты раз конфиги пишешь, а потом можешь развернуть почти на любом дистре (так как докер использует системное ядро, то это накладывает ограничения), неважно что там Debian, RHEL и тп, главное чтобы всталит docker, docker-compose. Кучи хостов у меня нету, мой буизнес до такого не дорос (у крупных контор рабы на зарплате)

memcache есть. Выключен

Мускуль хоть перенастроен из дефолта под твою конфигурацию?

воркер веб-сервера не эквивалентен пользователю на сайте. один пользователь тебе может нагенерировать стопицот тыщ мульенов запросов и воркеров повернув на сайте одну кнопочку, ну.

мне трудно ответить на этот вопрос. т.к. занимаюсь этим пару месяцев. Как это проверить?

Отвечаю: тот же postfix проще в контейнере поднять чем мучаться с его настройкой, с постгре и нгинксом у тебя может проблем и не будет

Да при чем тут постфикс? Да, постфикс, питон, пхп тяжело настраивать и распространять, как это и положено в никсовых приложениях. Постгря и nginx — это эталонные нениксовые приложения, они должны были быть windows-only с их неадекватной склонность работать из любого каталога.

Вопрос был про СУБД в контейнерах. Особенно постгря, для которой вообще нет проблемы сделать тарбол с дистром и просто распаковывать его на целевом сервере.

С gitlab’ом: он образы по коммитам собирает, а watchtower когда видит, что появился новый образ, собирает контейнер с последней версией приложения, останавливает текущий, запускает новый. Мне вручную ничего делать не нужно

Не, я в курсе. что он делает — я не в курсе. почему именно GitLab, когда етсь столько альтернатив:

https://github.com/ligurio/awesome-ci

Например:

https://github.com/concourse/concourse
https://github.com/drone/drone

тяжело настраивать и распространять, как это и положено в никсовых приложениях

лень - двигатель прогресса. не нравится докер, пиши конфиги для ансибла чтобы он твое приложение разворачивал автоматом

Постгря и nginx — это эталонные нениксовые приложения, они должны были быть windows-only с их неадекватной склонность работать из любого каталога

то что стоит на любом серваке

Вопрос был про СУБД в контейнерах. Особенно постгря, для которой вообще нет проблемы сделать тарбол с дистром и просто распаковывать его на целевом сервере.

логика же простая: если у тебя часть приложения запускается в докере, то пихаем в контейнеры и все остальное. ты там будешь для системд всякие конфиги писать чтобы приложение можно было удобно запускать/останавливать. куча-куча конфигов, которые по отдельности надо обслуживатья, а с докером у тебя один docker-compose.yaml и все сервисы разом можно перезапустить с помошью docker-compoes up -d`. накладные расходы все равно небольшие: немного процессорного времени, немного памяти… через докер можно ограничить использование процессора и памяти контейнером, но этим мало кто пользуется. самое главное - простота.

МИНУСЫ же есть и огромные: диффы контейнеров из-за частых сборок занимают сотни гигабайт. За неделю скапливается гигабайт 100 артефактов (подконтрольная мне группа из 4 разработчиков)

В сети куча статей о настройке мускулы. Почитай, сравни со своей конфигурацией.