14 ноября 2020 в 21:58
Всегда хочу быстрее и лучше )
В целом все работает в приделах допустимой нормы но может у кого то есть рецепты\конфигуркции так званные best practices конфигурации базы данных под drupal 8/9 что бы все летало
в частности сервер 4 ядра 16 гиг озу(клево и на 8 гиг)
Буду благодарен если кто то поделиться лучшей практикой)
Комментарии
самые быстрые запросы в базу - это когда нет никаких запросов в базу
а ещё лучше, когда на уровне варниша всё заканчивается, не запуская друпал
Конечно клево, но варнишь никак не справиться если к примеру нужно обновить 100к нод.
А когда работаешь с таким объемом и нужно регулярно (раз в сутки это делать) то в любом случаи нужно дергать сайт без варниша.
И конечно же на таком объеме я чувствую каждые 10мс которые превращаются в 15-20 минут на объеме.
если вам нужно обновлять 100к ежедневно, то скорее всего, выбрав друпал, вы что-то сделали не так
Выбрав к примеру ту же симфонию получу такой же результат.
можно написать какой то самописный линейный код, но как же тогда расширяемость удобство и т.д.
В целом проект достаточно сложный и обширный, и то что нужно делать апдейт 100к материалов это хоть и обязательная часть, но очень малая часть проекта, под все остальное друпал идеально вписывается со своими вюхами. ролями пользоватлей регистрацией форм и т.д.
p.s. обновление идет через queen, в целом в течении ночи справляется все без особого вреда как на сервер так и на сайт. Есть идеи как организовать апдейты по 50 нод сразу прямыми запросами базы данных, что очень сильно сократит время, и будет около 5-60 секунд, но это вообще тема другого разговора, да и особо не проблема сейчас.
Вопрос ведь более глобальный и широкий.
В целом варнишь это отличный инструмент и должен быть у большенства.
И можно отдельную ветку запулить где поделиться своим конфигом варниша, а еще лучше на много виртуальных доменов что бы был варниш.
Но сейчас речь о mysql если есть чем поделиться буду очень рад. Возможно что то применю и к себе
в симфони порядок легче и модели, и бутстрап, поэтому результат далеко не такой же
и прямая запись в базу, если не забывать заодно кештег чистить - это вполне себе решение, когда надо гнаться за производительностью
конфиг базы можно https://github.com/wodby/mariadb тут посмотреть
Конфиг базы очень зависит от проекта и наличных ресурсов.
Тот что по умолчанию по ссылке, часто будет совсем не оптимальным, тем более на сервере - он для очень скромных ресурсов, чтобы этот контейнер можно было на любом чайнике запустить, вероятно.
Как и при простой установке, в реальном проекте, надо менять настройки. Контейнеры отнюдь не избавляют от необходимости самостоятельного конфигурирования серверного ПО, просто иногда делают процесс развёртывания удобнее, не более - обратное это очень опасное заблуждение...
может надо какой-н кластер настроить https://habr.com/ru/post/253869/
или почитать статьи на производительность https://habr.com/ru/search/?target_type=posts&q=%5Bmysql%20performance%5...
С кластером интересно, но в моем случаи не совсем подходит, так как это сервер под сотни полторы сайтов.
"сервер под сотни полторы сайтов" - интересно. у меня свой сервер. можете рассказать вкрадце программную конфигурацию. меня интересуют лучшие практики. например в какой конфигурации вебсервер и пхп, используются ли acl, используется какая либо админка, как происходит разграничение пользователей и системы ?
использую морду для клиентов ispmanager
так же докеры крутятся для внутрених целей и работ(redmine на нем и еще несколько фич)
самые посещаемые сайты и те сайты которые сопровождаю сразу перевожу на nginx+php-fpm
остальные сайты работают в связке nginx-apache-php-fpm
Таким образом для каждого пользователя создается один процес apache который прожерлевый, но позволяет работать пользователям с файлом htaccess, а для посетителей сайтов отдает данные nginx экономя драгоценный ОЗУ.
Для очень посещаемых сайтов (буквально штук 5) еще поднят varnish, но для того что бы не выходить с общей концепции, и так как порт 80 и 443 занят nginx то связка немного не стандартная
nginx(80/443)-varnish(только с localhost и любой настраевыемый порт)-nginx(рандомный порт который который сгенерирует контент)
или же nginx(80/443)-varnish(только с localhost и любой настраевыемый порт)-nginx(рандомный порт который который сгенерирует контент)-apache(любой порт)
Экспериментировал с redis и memcached но не увидел профита
с базой экспериментировал поднять несколько на docker и разделить нагрузки. но профита не увидел, даже наоборот.
Ввиду того что нагрузка не с одного сайта, а с многих эмулировать нагрузку сложнее.
Поэтому более длинные тесты, и анализы графиков нагрузок.
Сервер
8гиг озу(с неделю назад перевел было 16, увидел что все равно +- вписываюсь в
+ добавил своп на 10 гиг(на всякий случай, реально используется 2-3 гига)
4 ядра процессор(по 2,5ггц)
nvme винчестер.
Не давно перевел базу на отдельный диск, в целом проблема не в iops а в том что место заканчивалось, и решил на отдельном диске крутить базу, тем самым освободив место на основном)
большинство сайтов на стандартном opcache который крутится на php7.2-7.4, хотя у пользователей есть возможность выбирать php начиная с 5.5
жду выхода php 8.0 потихоньку тестирую его.
текущие нагрузки вот такие
Если буду упираться в ram\cpu просто сменю VPS причем на лету все пересобирается за минут 10-15
Но если хочу 8 процессоров, то нужно платить за VPS почти в 2 раза больше, пока не вижу необходимости, в целом все работает
так же на сервере настроены инкрементные бекапы, и есть 30 дневные бекапы.
Конечно. База в докере будет медленее. И несколько инстансов баз в рамках одного сервера даже без контейнеров, будут затратнее по ресурсам и не будут быстрее.
Распределение нагрузки, это когда есть несколько дополнительных серверов СУБД, а не несколько инстансов СУБД на том же железе.
Профит зависит от приложения, и использования этих механизмов. Сами по себе не помогут. Некоторые виды кеша там бывает очень выгодно хранить, некоторые нет.
Да, это действительно сильно усложняет процесс и делает многие приёмы менее эффективными, т.к. почти все тонкие настройки это компромисс между чем-то и чем-то, а требования и поведение у разных приложений отличаются.
При таких ресурсах уже надо будет брать не виртуальный сервер - это будет дешевле, возможно, даже дешевле чем сейчас виртуалка...
Надеюсь, они делаются куда-нибудь вовне?
Спасибо за интересную информацию. Я админю 4 друпал сайта. 2 размещены у меня в рамках тестовой эксплуатации 2 на сторонних хостингах. Как доведу свой сервер до требуемого качества то буду предлагать для использования коммерческих сайтов. Пробовал панели управления vestacp ispconfig ispmanager - они все мне не понравились потому что выходит машина из под твоего контроля. Люблю управлять скриптами. Все сайты на друпал. Конфигурация сейчас это апачи +пхп-фпм + Мариядб. Уделяю внимание информационной безопасности. Потому интересуюсь.
Железо 8 гиг китайской оперативы, проц Пентиум 4 ядра TDP 6 ватт. 2.3Ггц. Производительности хватает. Виртуальные машины не использую но планирую поиграться с контейнерами . Инкрементальный бэкап на другой носитель. это хобби с прицелом на профессионализм.
ispmanager полный контроль никак не противоречит, isp побольшому счету морда которая автоматично прописывает apache и nginx + разделяет пользователей, ставит им квоту(так же прописывая автоматично конфигы)
то есть по факту Вам никто не мешает самому что то свое накрутить, более того автоматизировать накручивания(можно те же шаблоны для nginx написать и скормить isp что бы он брал твои шаблоны)
Тем мне и понравился isp, если взять ту же cpanel там гораздо сложнее все накручено.(хотя для пользователя немного больше возможностей)
Мне лично не нужна админка что бы создать еще один виртуалхост или базу. Но откровенно говоря командами или через конфиги создавал базу\виртуалхост последний раз очень давно, хотя на локальном компьютере делаю регулярно. Через админку гораздо проще и удобней.
И самое главное мои пользователям не нужна консоль им нужна админка.
Более того isp умеет создавать ssh юзера под пользователя, и это так же удобно
Единственный хороший совет: не искать готовые советы. Просто не существует универсального решения на все случаи жизни.
По уму, надо осваивать mysql, смотреть что и как можно настроить для именно вашего случая, или найти кого-нибудь, кто это уже знает.
В самом простейшем случае, можно проверить конфигурацию каким-нибудь mysqltuner, и разобраться что, и почему именно, он советует изменить, а не просто копипестить советы в конфиг. И надо понимать, что это всё равно советы для общего случая, не более - им далеко не всегда имеет смысл следовать.
Полностью согласен. Без думно не годится. Но если посмотреть пример, вот есть сервер такие то параметры, вот так вот настроено и работает молненосно. Взять вот эти настройки под себя подкрутить, обратить на что то внимания очень удобно и полезно. Возможно с уточнениями обратить внимание на эти параметры очень сильно ускоряют производительность но оперативку жрет.
Тюнинг настроек происходит не так. Это цикл из измерений и изменений, и это даже если знаешь, что как работает.
Каких-то настроек, которые во всех случаях сделают wow, просто нет. Поэтому довольно бесполезно смотреть какие-либо примеры. Особенно в вашем случае, со сборной солянкой из разных проектов.
Сейчас, конфиг по умолчанию что для mysql, что для mariadb сносен, уже не задавлен так innodb_buffer_pool тот же как раньше.
Более или менее общая рекомендация, пожалуй, менять innodb_file_per_table=ON, но она не с производительностью связана.
Ну и innodb_buffer_pool/innodb_buffer_pool_instances, по возможности увеличить, всё же, если данных много, и есть возможность на это потратить память(не больше суммарного размера данных - дальше не будет смысла).
Вероятно, этим и кончается что-то, что делается просто из общих соображений и предсказуемо.
А что-то более серьёзное крутить имеет смыл только мониторя результаты, и понимая что это вообще.
Vps беру на хезтнере, не даже если брать на 8 ядерь все равно выгодно вас а не что то выделенное или колокейщен.
Насчёт бекапов да отдельно, для удобство конекчу по nfs раздел и туда бекапы складываю
На аукционе того же хетзнера можно взять начального уровня сервер на чём-то типа e3-12xx с ssd от e35 где-то.
Такая же по характиристикам виртуалка без оверсела у них стоит e83. Это ccx31. Даже с 4 ядрами ccx21 стоит уже дороже сервера(e41.88).
cpx31, которая дешевле значительно, не имеет гарантированных вычислительных ресурсов. Вам там не отдают реальные 4 ядра, собственно она и стоит так поэтому.
Хетзнер хорош только лоу кост серверами. Для размещения vps я бы смотрел на что-то другое...
Берём Клауд и берём не выделенные ядра. Ядра распределяются между 3 пользователями.
В итоге все достаточно стабильно и хорошо работает
Клауд очень удобен в управлении и стабильный.
Это не сочетается с "быстрее и лучше".
У меня все работает хорошо на cpx31 было на cx41
оперативку мы уж точно не делим ни с кем )))
Если процессора станет мало то возьму cpx41 и пока будет запаса на долго
А еще если в Хенкель брать, то ПДВ не считают, поэтому от цен отнимай 20% с того что на сайте
С учетом что я взял дополнительный value на 50 гиг(2евро) + сервер 12 евро, то в месяц мне обходится 14 евро... Что очень даже выгодно, и брать сервер в 2-3 раза дороже нет смысла даже если перееду на более высокий сервер 22,2евро все равно выгодно, и пока не вижу смысла менять.
И то что есть такие решения очень классно, так как до не давних пор покупал колекейшин с своим сервером, с идеей "я могу поставить крутое железо, будет афигено", в итоге платил по 70-100$ в месяц железо крутилось на 1500$ а оно вообще не нужно было. + винт слител что стало стимулом быстро решать вопрос, пока второй не слител, порешал, и прозрел насколько все дешевле, и не в убыток производительности(конечно тут от задач зависит, но получилось так что я сервер не использовал полноценно так как не было на него таких задач)
Это просто значит, что либо нет загрузки на этой ноде, либо просто и не надо столько ресурсов.
Но это всё может очень быстро измениться. Вариант с меньшим количеством выделенных ядер, надёжнее и более прогнозируем. В вашем случае надо рассматривать эту виртуалку как 1,5 ядра в лучшем случае, и сравнивать именно в этом ключе. А вообще, всё даже хуже, потому, что многие операции не распараллеливаются, и выгоднее иметь меньше но более быстрых ядер.
Ну и да, конечно это не надо менять на сервер.
Колокейшен в принципе имеет смысл только для стоек, а железо не надо покупать. В лучшем случае это лизинг.
Одиночные серверы дешевле арендовать. Ну и гонка за производительностью как таковой, конечно крайне вредна.
Уже немного больше года все хорошо.
Насчет того что много задач не распараллеливается и да и нет. В рамках веб сервера apache nginx mysql умеет паралелить, а это 99% всего что нужно веб серверу.
Если даже будут заметны проблемы то цена вопроса 10-15 минут что бы сменить vps тарифный план где можно с зарезервированными полноценными процессорами и даже если это и нужно будет(хотя сомневаюсь в рамках моих задач), то можно взять этот VPS и паралельно поставить rsync на выделенный другой, оплатив за дорогой VPS буквально 1-2 дня пока буду переезжать, дальше настроить прокси трафика что бы увидеть что все нормально переехало еще какой то максимум день, не так много будет оплачено, но снова таки это экстренные пути которые есть и не сложные. Так что по факту то что есть все работает хорошо, причем больше года.
Один поток php или один запрос mysql(в 8 кстати, ведутся работы чтобы это изменить) исполняются на одном ядре, и запросы mysql одного http запроса исполняются последовательно... Именно эти операции занимают почти всё время в случае веб приложения на этом стеке. Увеличение количества ядер даёт не ускорение исполнения приложения, а возможность обрабатывать больше запросов в единицу времени. А вот увеличение производительности ядра даёт, и то, и другое.
В нормальных проектах 1-2 дня тормозов, конечно не допустимы.
В общем, я не говорю, что этим нельзя вообще пользоваться, я говорю, что это совсем не всегда лучший вариант, а иногда просто не приемлемый
И снова таки и да и нет )))
Стандартные сайты не нагружать в один поток, это не обработка бигдаты или кодирования видео, это куча мелких запросов с разных сторон, поэтому в неком смысле есть смысл в много ядер с меньшей мощностью )
Но конечно выделенный сервер с выделенными ядрами ещё и в кластере и с балансировкой лучше чем впс ) но гораздо дороже и смысла нет
Насчёт тормозов 1-2 дня то их не будет. Будет 10-15 минут раза два в течении 1-2 дней.
Первый раз когда будет пересобран образ что бы перейти на более дорогой тарифный план и исключить тормоза, и второй в момент переключение с дорогого впс на более выгодный выделенный сервер.
Конечно это не приятно и нужно стараться исключать и такие ситуации но в целом достаточно терпимо
Это таки-да, потому, что время исполнения каждого такого запроса важно. И вот оно, ограничено качеством, а не количеством ядер, т.е. добавлением ядер не уменьшить время генерации страницы. А отрезанием части производительности ядра гарантировано можно его увеличить, даже если рядом будут 100500 простаивающих ядер.
Возвращаемся к теме друпал, что бы сгенерировать страницу немного сложную с параграфами вюшками сайдбаром с блоками и т.д. сколько нужно запросов часто с хорошую сотню а то и больше но они все легинькие, запросы могут паралельно на ядрах выполняться (у нас селекты и таблица не блокируется) так вот на 4х ядрах плохих будет генерироваться быстрее чем на одном хорошем. (может не прав, нужны тесты, но у меня такое ощущение. )
Тем более если кто то занял процессор сложной длиной операциейя к примеру те же бекапы начали создаваться и 1 процессор очень сильно загружены то явно будет виграшь в работе сервера с несколькими плохими ядрами
При обработке одного запроса drupal будет использоваться фактически 1 ядро. Это будет фактически линейная цепочка вызовов php-mysql-php-mysql-php и.т.п. Каждый элемент которой, в каждый момент времени сможет занять только одно ядро. И на одном быстром ядре, запрос будет обрабатываться быстрее, чем на любом количестве медленных, просто потому, что остальные не смогут быть загружены в рамках одного запроса. То, что таблицы не блокируются, это плюс для соседних запросов, но не для этого же. У нас же тут не новомодно асинхронное всё.
Вообще, если у нас есть 4 ядра производительностью 1, и И два ядра производительностью 2, до очень высокой степени конкурентности, когда переключение контекста будет уже довольно дорогим, 2 ядра выигрывают. Это довольно универсально для любых задач, не только веб - фактически нет вещей, которые масштабируются по ядрам линейно.
Конечно, если рассматривать 2 ядра по 1,5 и 4 ядра по 1, то при достаточно конкурентности 4 выиграют из-за большей суммарной производительности. Но если это будет отдельный http запрос, то выиграют два. И до определённого RPS, будет выигрывать, потом сравняется, потом начнут проигрывать.