64-битный сервер с высокой памятью, не использующий все оперативные памяти
У меня есть несколько Linux-серверов с высокой памятью, работающих под управлением Centos 64bit, и после 10-20 дней безотказной работы я заметил, что на всех этих серверах они фактически не используют весь оперативный памяти, доступный на тот момент (все они имеют около 10 ГБ свободной в системе 48 ГБ, 20 ГБ бесплатно в системах 64 ГБ.
Они являются веб-серверами и имеют рабочий набор данных (например, активные файлы), превышающий количество оперативной памяти на сервере, поэтому я бы предположил, что кэш страниц будет расти до такой степени, что будет использоваться весь оперативной памяти, тогда как страницы из кэша страниц будет быть освобожденным, когда / если необходимо.
например:
top - 09:44:46 up 57 days, 9:32, 5 users, load average: 6.44, 6.33, 6.27
Tasks: 680 total, 4 running, 676 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.3%us, 3.3%sy, 0.0%ni, 79.0%id, 0.1%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 49313212k total, 39277524k used, 10035688k free, 1247064k buffers
Swap: 20643832k total, 0k used, 20643832k free, 20592968k cached
показывает, что этот сервер работал 57 дней, однако имеет 10 ГБ свободной памяти, которую следует использовать в кэше страниц.
Следующие sysctl устанавливаются на складе centos:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
error: "kernel.maps_protect" is an unknown key
net.core.rmem_default = 8388608
net.core.wmem_default = 8388608
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 20000
vm.min_free_kbytes = 85536
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 6000
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_fin_timeout = 40
net.ipv4.tcp_keepalive_time = 1000
net.ipv4.tcp_keepalive_probes = 2
net.ipv4.tcp_keepalive_intvl = 30
net.netfilter.nf_conntrack_tcp_timeout_established = 2000
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1
kernel.panic = 40
fs.proc_can_see_other_uid = 0
net.ipv4.ipfrag_secret_interval = 6000
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_tw_buckets_ub = 720000
net.core.optmem_max = 25165824
fs.proc_can_see_other_uid = 0
fs.proc_super_gid = 32010
vm.swappiness = 2
fs.file-max = 400000
fs.suid_dumpable = 1
kernel.msgmni = 1024
kernel.sem = 250 256000 32 1024
Я пытался изменить один от многих sysctl! и надеюсь, что какая-то добрая душа видела это раньше, заранее спасибо за любую помощь.
3 ответа
Я возвращаюсь сюда, чтобы ответить на мой собственный вопрос!
Проблема возникает, когда у вас есть несколько процессоров (не многоядерных), например, 2 процессора с x ядрами
vm.zone_reclaim_mode=0
исправляет это.
Я не уверен, что здесь есть проблема. Вы испытываете другие проблемы, такие как высокий дисковый ввод-вывод?
Большинство программ не предназначены для использования всей памяти только потому, что могут. Вы не упоминаете, какое программное обеспечение веб-сервера вы используете, но большинство программ веб-сервера будут иметь внутренние алгоритмы, предназначенные для удаления объектов из кэша, если они не запрашиваются достаточно часто. Они также имеют настраиваемые механизмы, предназначенные для управления количеством ресурсов, которые они потребляют на сервере.
Предполагая, что вы используете Apache, в разделе настройки производительности документации Apache есть раздел о настройке MaxRequestWorkers:
Вы можете и должны управлять настройкой MaxRequestWorkers, чтобы ваш сервер не порождал столько дочерних элементов, он начал обмениваться. Эта процедура для этого проста: определите размер вашего среднего процесса Apache, просматривая список процессов с помощью такого инструмента, как top, и разделите его на общую доступную память, оставляя место для других процессов.
Если вы используете Apache, и если вы это сделали, то вполне вероятно, что у вас недостаточно запросов для Apache, чтобы оправдать поддержку всех этих работников. Возможно также, что ваша оценка количества работников слишком мала, и вы можете увеличить MaxRequestWorkers, чтобы попытаться заставить Apache порождать больше работников.
Если вы не испытываете какую-то другую проблему, это не похоже на что-то не так. Но в любом случае, это, вероятно, вопрос / проблема конфигурации программного обеспечения веб-сервера, а не sysctl.
Любая оперативная память, не используемая для программ, используется в качестве дискового кэша. Таким образом, в теории, все ОЗУ используется. Отличное объяснение здесь: http://www.linuxatemyram.com/