Я размещаю веб-сайт для клиента на выделенном VPS с 512 МБ ОЗУ. За последние 2 недели он дважды отключился из-за 0% свободной памяти (или свободного свопа). Сайт довольно интенсивно использует базу данных, поскольку на нем работает Drupal с более чем 60 модулями. В среднем (по данным владельца сайта) он получает около 6000 посетителей в месяц (~ 200 в день). Хотя, вероятно, он будет расти довольно быстро - он был запущен менее года назад.
Итак, я сажусь, чтобы наконец разобраться в Apache. Раньше я вручную настраивал httpd.conf, но не понимал всех тонкостей.
Я узнал, что мне следует рассчитать средний размер процесса Apache в мегабайтах с помощью MaxClients, и что это число не должно превышать объем памяти, доступной системе. Согласно Top, размер каждого процесса немного меньше 7% (это было бы около 1,4 МБ, не так ли?). 512 / 1,5 = 341 ... мне это кажется ужасно большим. Я что-то не понимаю? Сначала подумал, что надо посчитать размер процесса в процентах (в данном случае ~ 7). Может быть, я был прав с первого раза?
Это дает немного места для других процессов ОС.
База данных (MySQL) находится на том же хосте.
У меня двоякий вопрос. 1) Я подумываю об установке Varnish, чтобы уменьшить нагрузку на базу данных (почти все посетители не прошли проверку подлинности), чтобы ускорить начальное время отклика и т. Д. Я сошел с ума от системы с таким небольшим объемом памяти? Думаю дать ему 256Мб, если так и сделаю. Мысли? Очевидно, что в кеше ничего не осталось бы. 256/7 = ~ 36 страниц. Однако я надеюсь, что «основные» страницы будут кэшированы. Домашняя страница и некоторые из основных страниц, лежащих в основе домашней страницы, будут довольно интенсивно использовать базу данных, и я хотел бы максимально уменьшить объем дискового ввода-вывода.
2) Если бы я установил Varnish, мне было бы интересно, следует ли мне настроить Apache наполовину по сравнению с текущим значением, поскольку я выделил Varnish половину памяти. Какая связь между Varnish и Apache в этой низкоуровневой конфигурации?
Вам нужно получить виртуальную машину большего размера. Вы начинаете свой пост, сообщая нам, что ваша виртуальная машина уже дважды "зависла" из-за нехватки памяти и подкачки. Как добавление еще одного приложения, которое использует большой объем памяти, может помочь в вашей ситуации? Не будет.
Давайте разберем вашу маленькую виртуальную машину и ее использование памяти.
Во-первых, у вас есть 512 МБ оперативной памяти. Возьмите от 100 до 125 МБ (20-25%) этого и полностью удалите из своих расчетов. Эта оперативная память необходима вашему ядру, поддерживающим процессы, буферы и кеш. Это оставляет вам 400 МБ ОЗУ (разделите разницу).
Допустим, вы хотите использовать половину своих 400 МБ, дав MySQL 200 МБ. Позвольте мне прояснить, что я не знаком с требованиями Drupal и с тем, использует ли он MyISAM или InnoDB. Если бы вы настраивали InnoDB, вы бы использовали innodb_buffer_pool_size переменную и просто установите ее на 200M. Вы можете ожидать, что MySQL будет использовать Больше чем это, однако, для таких вещей, как кеш запросов (если используется), открытые таблицы, обработка соединений, отслеживание потоков, буферы сортировки, буферы соединения и бесчисленное множество других параметров конфигурации. Если вы используете MyISAM, это еще сложнее, потому что здесь задействовано гораздо больше переменных, key_buffer и myisam_sort_buffer всего лишь два из нескольких. Итак, если предположить, что InnoDB с 200M innodb_buffer_pool_size а кеш запросов отключен, допустим, MySQL потребляет 216 МБ ОЗУ.
Теперь у вас осталось 184 МБ ОЗУ для использования Apache. Во-первых, давайте займемся моментом, чтобы прояснить некоторые действительно запутанные вещи в вашем вопросе.
Я узнал, что мне следует рассчитать средний размер процесса Apache в мегабайтах с помощью MaxClients, и что это число не должно превышать объем памяти, доступной системе.
Нет. Вы наблюдать ваш средний размер процесса httpd, когда ваш сайт используется. Используя средний размер каждого процесса httpd (при условии, что MPM prefork используется по умолчанию), вы вычисляете, что MaxClients может быть так, что вы не превысите объем памяти, выделенный для httpd или машины, что приведет к его подкачке.
Согласно Top, размер каждого процесса составляет чуть меньше 7% (это было бы около 1,4 МБ, не так ли?). 512 / 1,5 = 341 ... мне это кажется ужасно большим. Я что-то не понимаю?
Да Вы. Во-первых, прекратите использовать проценты для «вычисления» размера процессов httpd.
редактировать
Подождите! Какой? 7% от 512 это 35,84. Не знаю откуда у вас 1.4 Мб. Мой ответ все еще в силе, и я не буду корректировать свой ответ, чтобы компенсировать ваши 35 миллионов процессов httpd.
Конец редактирования
Размер процессов httpd четко указан вверху под RES столбец. Например:
top - 21:48:44 up 168 days, 4:46, 1 user, load average: 0.02, 0.09, 0.08
Tasks: 66 total, 2 running, 64 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2072832k total, 1994784k used, 78048k free, 407976k buffers
Swap: 787176k total, 300k used, 786876k free, 1321988k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8725 mysql 20 0 729m 69m 3396 S 0.0 3.4 53:45.84 mysqld
22217 apache 20 0 161m 17m 7960 S 0.0 0.9 0:08.42 apache2
26193 apache 20 0 161m 16m 6944 S 0.0 0.8 0:00.26 apache2
4470 apache 20 0 161m 16m 6948 S 0.0 0.8 0:01.52 apache2
6193 apache 20 0 161m 15m 6608 S 0.0 0.8 0:01.35 apache2
4014 apache 20 0 161m 15m 6616 S 0.0 0.8 0:01.48 apache2
6939 apache 20 0 161m 15m 6608 S 0.0 0.8 0:01.48 apache2
6685 apache 20 0 161m 15m 6608 S 0.0 0.8 0:01.32 apache2
26146 apache 20 0 161m 15m 6604 S 0.0 0.8 0:00.38 apache2
6443 apache 20 0 161m 14m 5712 S 0.0 0.7 0:01.38 apache2
26450 apache 20 0 161m 14m 5704 S 0.0 0.7 0:00.19 apache2
2524 root 20 0 159m 13m 5524 S 0.0 0.6 0:03.34 apache2
Технически память, используемая на процесс, разница в RES и SHR (общий). Это потому что SHR это память, разделяемая другими процессами. Вы можете видеть на примере, который я вам показал, в среднем это примерно 9 МБ, для моего уникального варианта использования. Это просто машина, на которой работает Cacti, практически без трафика - может быть, 5-10 обращений в день, если я случайно взгляну на нее. Я скептически отношусь к тому, что Drupal использует так мало памяти, но вы легко сможете это сказать. Это определенно использует намного больше 1,4 МБ.
Теперь давайте возьмем очень нереально предполагается, что ваши процессы httpd будут каждый раз использовать даже 10 МБ ОЗУ. Если для Apache «выделено» 184 МБ ОЗУ, остается 18 MaxClients (10 МБ * 18 = 180 МБ). Много много менее 341.
Во-первых, давайте оценим текущее состояние вашего сервера. Предполагая, что вы правильно настроили MySQL и httpd, чтобы они не менялись под нагрузкой, вы работаете с тем, что довольно анемичный Конфигурация MySQL и конфигурация httpd, которая начнет отклонять запросы, если вы когда-либо получите более 18 одновременных запросов. По любым стандартам эта машина не в состоянии обрабатывать трафик, который будет «очень быстро расти».
Теперь вы хотите добавить третье приложение и выделить ему 256 МБ ОЗУ ?! Эта оперативная память должна быть получена из MySQL или Apache, и, возможно, вам удастся украсть часть из самой ОС. В любом случае вы добавляете одну из основных служб на свой компьютер.
Это технически возможно что вы можете найти золотую середину настроек конфигурации для Varnish, Apache и MySQL на одном хосте, что позволяет всем работать с идеальной эффективностью с просто нужное количество оперативной памяти, но я настроен скептически.
Используйте то, что я научил вас правильно настраивать MySQL и Apache, чтобы сделать именно это: настроить их правильно. Ваш MaxClients должно быть далеко не 300, скорее всего, меньше 20, а вполне возможно, меньше 10. Еще одна вещь, о которой я не упомянул, - это то, что процессы httpd могут неохотно отказываться от ОЗУ, когда они «достигли пика» намного выше среднего. например Если рабочий httpd ударил 20 МБ для одного запроса, этот рабочий будет продолжать использовать 20 МБ бесконечно (afaik), пока он не будет получен. Вы можете решить эту проблему, снизив MaxRequestsPerChild настройка. Понижение этого значения означает, что дочерние процессы выполняются чаще. Это замедлит вашу производительность под нагрузкой (разветвление новых процессов относительно дорого), но это поможет сохранить управляемость использования памяти.
При правильной настройке ваш сервер никогда не должен менять местами. Если вы правильно настроили свой сервер и видите такие проблемы, как отказ в подключении под нагрузкой, я бы предложил либо расширить вашу виртуальную машину, либо подумать о добавлении Varnish на отдельной выделенной ВМ.
Вы идете в правильном направлении, читая документацию и обращаясь за помощью в Интернете. Если вы застряли или вам нужна подробная помощь, задайте другой вопрос, но не забудьте сначала поискать! Вполне возможно, что ответ можно найти в другом.