Мой сервер получает высокий трафик c и достигает своих пределов, какой должна быть моя новая структура? - PullRequest
Новая
       32

Мой сервер получает высокий трафик c и достигает своих пределов, какой должна быть моя новая структура?

1 голос
/ 14 апреля 2020

Текущая конфигурация:

16 GO ОЗУ, 4 ядра процессора, Apache / 2.2 с использованием модуля prefork (для которого установлено значение 700 maxClients, поскольку средний размер процесса ~ 22 МБ), с включенными модами suexe c и su php (PHP 5.5).

Серверная часть сайта с использованием CakePHP2 и хранением на сервере MySQL. Сайт состоит из текста / некоторых сжатых изображений спереди и обработки данных сзади.

Текущий трафик c:

~ 60000 уникальных посетителей ежедневно, в Пики Я в настоящее время легко достигаю 700+ одновременных соединений, которые заполняют MaxClients. Когда я использую apachectl status в эти моменты, я вижу, что тогда используются все процессы.

Процессор в порядке. Но оперативная память становится все более используемой.

Потенциальный трафик c:

Объем трафика c может возрасти до ~ 200 000 уникальных посетителей в день или даже больше. Это может также не. Но если это произойдет, я хочу быть готовым. Поскольку я уже достиг пределов текущего сервера, использующего эту конфигурацию.

Поэтому я думаю о том, чтобы взять новый сервер, гораздо больший, например, с 192 ГБ ОЗУ и 20 ядрами.

Я мог бы сохранить точно такой же конфиг (что означало бы, что я мог бы обработать 10 * мой текущий трафик c с тем же конфигом).

Но мне интересно, есть ли лучшая конфигурация в моем случае, используя меньше ресурсов и быть настолько эффективными? (и это доказано)

1 Ответ

0 голосов
/ 15 апреля 2020

Скорость в секунду = RPS

Предложения для вашего раздела my.cnf [mysqld], 

thread_cache_size=100  # from 8 to reduce threads_created 
innodb_io_capacity=500  # from 200 to allow higher IOPS to your HDD
read_rnd_buffer_size=128K  # from 256K to reduce handler_read_rnd_next RPS of 129,942
thread_concurrency=6  # from 10 to expedite query completion with your 4 cores
slow_query_log=ON  # from OFF to allow log research and proactive correction

Эти изменения будут способствовать меньшей загрузке ЦП.

Наблюдения: A) 5.5.54 миновал конец жизни, более новые версии работают лучше. Б) Эти предложения - только начало возможных улучшений, даже с 5.5.4. C) Вы должны иметь возможность плавно перейти на innodb_file_per_table после включения опции. Ваши таблицы уже управляются механизмом innodb.

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

...