Сервер Linux использует только 60% памяти, затем происходит подкачка
У меня есть Linux-сервер, на котором работает наша система резервного копирования bacula. Станок работает как сумасшедший, потому что его тяжело менять. Проблема в том, что он использует только 60% своей физической памяти!
Вот результат free -m:
free -m
total used free shared buffers cached
Mem: 3949 2356 1593 0 0 1
-/+ buffers/cache: 2354 1595
Swap: 7629 1804 5824
и некоторый образец вывода из vmstat 1:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 1843536 1634512 0 4188 54 13 2524 666 2 1 1 1 89 9 0
1 11 1845916 1640724 0 388 2700 4816 221880 4879 14409 170721 4 3 63 30 0
0 9 1846096 1643952 0 0 4956 756 174832 804 12357 159306 3 4 63 30 0
0 11 1846104 1643532 0 0 4916 540 174320 580 10609 139960 3 4 64 29 0
0 4 1846084 1640272 0 2336 4080 524 140408 548 9331 118287 3 4 63 30 0
0 8 1846104 1642096 0 1488 2940 432 102516 457 7023 82230 2 4 65 29 0
0 5 1846104 1642268 0 1276 3704 452 126520 452 9494 119612 3 5 65 27 0
3 12 1846104 1641528 0 328 6092 608 187776 636 8269 113059 4 3 64 29 0
2 2 1846084 1640960 0 724 5948 0 111480 0 7751 116370 4 4 63 29 0
0 4 1846100 1641484 0 404 4144 1476 125760 1500 10668 105358 2 3 71 25 0
0 13 1846104 1641932 0 0 5872 828 153808 840 10518 128447 3 4 70 22 0
0 8 1846096 1639172 0 3164 3556 556 74884 580 5082 65362 2 2 73 23 0
1 4 1846080 1638676 0 396 4512 28 50928 44 2672 38277 2 2 80 16 0
0 3 1846080 1628808 0 7132 2636 0 28004 8 1358 14090 0 1 78 20 0
0 2 1844728 1618552 0 11140 7680 0 12740 8 763 2245 0 0 82 18 0
0 2 1837764 1532056 0 101504 2952 0 95644 24 802 3817 0 1 87 12 0
0 11 1842092 1633324 0 4416 1748 10900 143144 11024 6279 134442 3 3 70 24 0
2 6 1846104 1642756 0 0 4768 468 78752 468 4672 60141 2 2 76 20 0
1 12 1846104 1640792 0 236 4752 440 140712 464 7614 99593 3 5 58 34 0
0 3 1846084 1630368 0 6316 5104 0 20336 0 1703 22424 1 1 72 26 0
2 17 1846104 1638332 0 3168 4080 1720 211960 1744 11977 155886 3 4 65 28 0
1 10 1846104 1640800 0 132 4488 556 126016 584 8016 106368 3 4 63 29 0
0 14 1846104 1639740 0 2248 3436 428 114188 452 7030 92418 3 3 59 35 0
1 6 1846096 1639504 0 1932 5500 436 141412 460 8261 112210 4 4 63 29 0
0 10 1846104 1640164 0 3052 4028 448 147684 472 7366 109554 4 4 61 30 0
0 10 1846100 1641040 0 2332 4952 632 147452 664 8767 118384 3 4 63 30 0
4 8 1846084 1641092 0 664 4948 276 152264 292 6448 98813 5 5 62 28 0
Кроме того, вывод top, отсортированный по времени ЦП, похоже, поддерживает теорию о том, что своп - это то, что тормозит систему:
top - 09:05:32 up 37 days, 23:24, 1 user, load average: 9.75, 8.24, 7.12
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 76.1%id, 20.6%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4044632k total, 2405628k used, 1639004k free, 0k buffers
Swap: 7812492k total, 1851852k used, 5960640k free, 436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
4174 root 17 0 63156 176 56 S 8 0.0 2138:52 35,38 bacula-fd
4185 root 17 0 63352 284 104 S 6 0.0 1709:25 28,29 bacula-sd
240 root 15 0 0 0 0 D 3 0.0 831:55.19 831:55 kswapd0
2852 root 10 -5 0 0 0 S 1 0.0 126:35.59 126:35 xfsbufd
2849 root 10 -5 0 0 0 S 0 0.0 119:50.94 119:50 xfsbufd
1364 root 10 -5 0 0 0 S 0 0.0 117:05.39 117:05 xfsbufd
21 root 10 -5 0 0 0 S 1 0.0 48:03.44 48:03 events/3
6940 postgres 16 0 43596 8 8 S 0 0.0 46:50.35 46:50 postmaster
1342 root 10 -5 0 0 0 S 0 0.0 23:14.34 23:14 xfsdatad/4
5415 root 17 0 1770m 108 48 S 0 0.0 15:03.74 15:03 bacula-dir
23 root 10 -5 0 0 0 S 0 0.0 13:09.71 13:09 events/5
5604 root 17 0 1216m 500 200 S 0 0.0 12:38.20 12:38 java
5552 root 16 0 1194m 580 248 S 0 0.0 11:58.00 11:58 java
Вот то же, отсортированное по размеру образа виртуальной памяти:
top - 09:08:32 up 37 days, 23:27, 1 user, load average: 8.43, 8.26, 7.32
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 3.4%sy, 0.0%ni, 62.2%id, 30.2%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 4044632k total, 2404212k used, 1640420k free, 0k buffers
Swap: 7812492k total, 1852548k used, 5959944k free, 100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
5415 root 17 0 1770m 56 44 S 0 0.0 15:03.78 15:03 bacula-dir
5604 root 17 0 1216m 492 200 S 0 0.0 12:38.30 12:38 java
5552 root 16 0 1194m 476 200 S 0 0.0 11:58.20 11:58 java
4598 root 16 0 117m 44 44 S 0 0.0 0:13.37 0:13 eventmond
9614 gdm 16 0 93188 0 0 S 0 0.0 0:00.30 0:00 gdmgreeter
5527 root 17 0 78716 0 0 S 0 0.0 0:00.30 0:00 gdm
4185 root 17 0 63352 284 104 S 20 0.0 1709:52 28,29 bacula-sd
4174 root 17 0 63156 208 88 S 24 0.0 2139:25 35,39 bacula-fd
10849 postgres 18 0 54740 216 108 D 0 0.0 0:31.40 0:31 postmaster
6661 postgres 17 0 49432 0 0 S 0 0.0 0:03.50 0:03 postmaster
5507 root 15 0 47980 0 0 S 0 0.0 0:00.00 0:00 gdm
6940 postgres 16 0 43596 16 16 S 0 0.0 46:51.39 46:51 postmaster
5304 postgres 16 0 40580 132 88 S 0 0.0 6:21.79 6:21 postmaster
5301 postgres 17 0 40448 24 24 S 0 0.0 0:32.17 0:32 postmaster
11280 root 16 0 40288 28 28 S 0 0.0 0:00.11 0:00 sshd
5534 root 17 0 37580 0 0 S 0 0.0 0:56.18 0:56 X
30870 root 30 15 31668 28 28 S 0 0.0 1:13.38 1:13 snmpd
5305 postgres 17 0 30628 16 16 S 0 0.0 0:11.60 0:11 postmaster
27403 postfix 17 0 30248 0 0 S 0 0.0 0:02.76 0:02 qmgr
10815 postfix 15 0 30208 16 16 S 0 0.0 0:00.02 0:00 pickup
5306 postgres 16 0 29760 20 20 S 0 0.0 0:52.89 0:52 postmaster
5302 postgres 17 0 29628 64 32 S 0 0.0 1:00.64 1:00 postmaster
Я пробовал настроить swappiness параметр ядра на высокие и низкие значения, но, похоже, ничего не меняет поведение здесь. Я не понимаю, что происходит. Как я могу узнать причину этого?
Обновить: Система является полностью 64-битной, поэтому не может быть и речи об ограничениях памяти из-за проблем с 32-битными.
Обновление2: Как я уже упоминал в исходном вопросе, я уже пробовал настраивать подкачку для всех видов значений, включая 0. Результат всегда один и тот же, примерно 1,6 ГБ памяти остается неиспользованной.
Обновление 3: Добавлен верхний вывод к приведенной выше информации.
Вы привязаны к вводу-выводу. Ваша система - это маленький спасательный плот, разбитый в бурном море буферов / кешей / пейджинговых волн высотой 100 футов.
Вот это да. Просто вау. Вы перемещаете около 100 Мбайт / сек из вашего ввода-вывода, вы уже прошли 50% процессорного времени в ожидании ввода-вывода, и у вас есть 4 ГБ ОЗУ. Обратное давление на виртуальную машину этого сервера должно быть огромным. В «нормальных» обстоятельствах, когда система начинает буферизацию / кеширование, любая свободная оперативная память, которая у вас была, будет съеден заживо менее чем за 40 секунд.
Можно ли разместить настройки из /proc/sys/vm? Это даст некоторое представление о том, что ваше ядро считает "нормальным".
Те postmaster процессы также указывают, что вы используете PostgreSQL в фоновом режиме. Это нормально для вашей установки? PostgreSQL в конфигурации по умолчанию будет использовать очень мало ОЗУ, но после перенастройки на скорость он может быстро съесть 25% -40% доступной ОЗУ. Так что я могу только догадываться, учитывая их количество в выводе, вы используете какую-то производственную базу данных во время резервного копирования. Это не сулит ничего хорошего. Не могли бы вы рассказать подробнее, почему он работает? Каков размер параметра разделяемой памяти для всех postmaster процессы? Можно ли выключить службу или временно перенастроить базу данных, чтобы использовать меньшее количество подключений / буферов во время резервного копирования? Это поможет немного снизить нагрузку на уже загруженный ввод-вывод и освободить ОЗУ. Имейте в виду, что каждый postmaster процесс потребляет оперативную память сверх того, что база данных использует для внутреннего кэширования. Поэтому, когда вы вносите изменения в настройки памяти, будьте осторожны с тем, какие из них являются «общими», а какие - «для каждого процесса».
Если вы используете PostgreSQL как часть процесса резервного копирования, попробуйте перенастроить его, чтобы принять минимальное количество подключений, и не забудьте уменьшить параметры каждого процесса до разумного (всего несколько мегабайт каждый). Обратной стороной этого является то, что PostgreSQL выльется на диск, если он не сможет работать с набором данных в ОЗУ, как хочет, так что это действительно увеличение ваш дисковый ввод / вывод, поэтому настраивайтесь внимательно.
X11 сам по себе не занимает много памяти, но полный сеанс рабочего стола может потреблять несколько мегабайт. Выйдите из всех активных сессий и запустите соединение с консоли или через SSH.
По-прежнему, Не думаю, что это полностью проблема памяти. Если у вас более 50% ввода-вывода, подождите продолжительное время (а вы публикуете цифры, которые касаются 70-х), образовавшееся узкое место в конечном итоге приведет к разрушению остальной системы. Так же, как Дарт Вейдер давит шеи.
Сколько промыть темы вы настроены? Использовать
cat /proc/sys/vm/nr_pdflush_threads
узнать и
echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf
чтобы установить его в один поток. Обратите внимание, что последняя команда заставляет его постоянно загружаться после перезагрузки. Видеть 1 или 2 там нет ничего необычного. Если у вас есть несколько ядер или много шпинделя / шины для ввода-вывода, вам нужно увеличить их (немного). Больше потоков сброса = больше операций ввода-вывода, но также больше времени процессора, затрачиваемого на ожидание ввода-вывода.
Это значение по умолчанию или вы его изменили? Если вы столкнулись с этим, думали ли вы об уменьшении числа, чтобы уменьшить нагрузку на операции ввода-вывода? Или у вас есть огромное количество шпинделей и каналов для работы, и в этом случае вы подумали увеличение количество потоков смыва?
P.S. вы хотите установить для подкачки более низкие значения, а не более высокие значения, чтобы предотвратить подкачку. Наивысшее значение = 100 = поменять местами как сумасшедшие, когда кажется правильным, наименьшее значение = 0 = постарайтесь вообще не менять местами.
Если вы посмотрите на количество блоков, считываемых в секунду (bi) в разделе «IO», то вы увидите, что активность подкачки затмевается на несколько порядков. Я не думаю, что использование подкачки - это то, что вызывает сбой вашего диска, я думаю, что у вас есть что-то, работающее на коробке, что просто вызывает большую активность диска (чтение).
Я бы исследовал запущенные приложения и посмотрел, сможете ли вы найти виновника.
Производительность Bacula сильно зависит от базы данных. Скорее всего, именно postgresql убивает ваш сервер. Высокая средняя нагрузка и довольно большой процент времени, затрачиваемого на процессор в состоянии ожидания, ясно показывают, что он ждет дискового ввода-вывода ... И это делает PostgreSQL. Для каждого файла в вашей резервной копии задайте хотя бы оператор UPDATE. Не беспокойтесь об обмене.
Настройте установку PostgreSQL. Можно дать отдельной базе данных (или даже таблицам) собственные наборы дисков / рейдов для распределения операций ввода-вывода. Вы можете заставить PostgreSQL использовать асинхронную запись, если это еще не сделано ... Хотя это торгует целостностью базы данных для производительности записи. Чертовски увеличьте общую память, доступную PostgreSQL. Это облегчит чтение базы данных по крайней мере. Если вы никогда этого не делали, запустите VACCUM ANALYZE в базе данных Bacula, чтобы дать оптимизатору запросов что-то для работы.
Безусловно, самым слабым местом Bacula являются зависимости базы данных (и бессмысленность некоторых из них ...). Выполните очистку недавней большой резервной копии и обратите внимание, сколько времени (часто часов) требуется для выполнения пары десятков миллионов запросов. .. Bacula любит сравнительно немного больших файлов, иначе это собака.
Посмотрите, отвечает ли эта ссылка на некоторые из ваших вопросов. Я регулярно вижу, как Linux выгружает память (а не подкачивает ее) задолго до 60% использования. Это ожидаемая часть настройки его памяти:
http://www.sheepguardingllama.com/?p=2252
Но меня беспокоит ваше отсутствие буферов / кеша. Это выглядит очень необычно. Так что я думаю, что что-то еще не так.
Можете попробовать полностью отключить своп?
swapoff /dev/hdb2
или что-то подобное - по крайней мере, это подтвердит, что это ваша проблема, а не что-то еще.
По умолчанию swappiness установлено на 60.
cat / proc / sys / vm / swappiness 60
Swappiness - это ядро, используемое для настройки того, насколько ядро поддерживает обмен по RAM; высокая степень подкачки означает, что ядро будет часто заменяться, а низкая подкачка означает, что ядро будет пытаться не использовать пространство подкачки.
Мы можем изменить это редактируя значение vm.swappiness в /etc/sysctl.conf.
Вы можете вручную установить обмен ядра, которое вы можете увидеть на /proc/sys/vm/swappiness или отдав команду sysctl vm.swappiness. Swappiness - это параметр ядра, который определяет, сколько используется swap.
Установив sudo sysctl vm.swappiness=0 вы фактически деактивируете раздел подкачки. Чтобы сделать это изменение постоянным, вы можете добавить / изменить vm.swappiness=0 в /etc/sysctl.conf. Вы должны увидеть, что для вас выгодно. Я лично настроил его на vm.swappiness=10, 60 - значение по умолчанию.
Еще одна вещь, на которую вы, возможно, захотите посмотреть, - это очередь выполнения вашего ядра и непрерываемые процессы (столбцы «r» и «b» в vmstat) - это индикатор того, что система временами перегружена. Кстати, не путайте насыщенность с использованием ... настоящий проблема может быть в нехватке стека процессов по сравнению с насыщенным ядром :-(
Вы также можете запустить pmap -x [PID], чтобы получить дополнительную информацию о памяти от некоторых из наиболее ресурсоемких процессов. Желаю тебе удачи!
Мэтт
Возможно, у вас есть недолговечные процессы, которые используют много памяти, а затем выйдите, прежде чем вы их заметите.
В любом случае это будет соответствовать тому, что вы видите.
Вы исследовали проблемы с кешем inode? slabtop должен по крайней мере дать вам отправную точку, если вы столкнетесь с чем-то вроде этого.
В то время как ваша система 64-битная, она может быть не в состоянии адресовать всю доступную память. Это ограничение чипсета. Например, Mac mini предыдущего поколения «поддерживает» 4 ГБ оперативной памяти, но фактически адресуемыми были только 3,3 ГБ.