Сервер 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, отсортированный по времени процессора, кажется, поддерживает теорию, что swap - это то, что утомляет систему:

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: добавлен верхний вывод к вышеуказанной информации.

Производительность Bacula сильно зависит от базы данных. Вероятно, именно postgresql убивает ваш сервер. Средняя загрузка и довольно большой процент времени процессора, проведенного в состоянии ожидания, ясно показывают, что он ожидает дискового ввода-вывода ... И это делает PostgreSQL. Для каждого файла в вашей резервной копии необходимо выполнить как минимум оператор UPDATE. Не беспокойся об обмене.

Настройте установку PostgreSQL. Возможно, предоставьте индивидуальной базе данных (или даже таблицам) свои собственные наборы дисков / рейдов для распределения ввода-вывода. Вы можете заставить PostgreSQL использовать асинхронную запись, если это еще не сделано ... Хотя это обменивается целостностью базы данных на производительность записи. Ударить из общей памяти, доступной для PostgreSQL. Это облегчит, по крайней мере, большую часть чтения в базе данных. Если вы никогда этого не делали, запустите VACCUM ANALYZE в базе данных Bacula, чтобы оптимизатор запросов мог с чем-то работать.

Безусловно, самое слабое место Bacula - это зависимости от базы данных (и умственные способности некоторых из них ...). Выполните очистку недавней большой резервной копии и обратите внимание, сколько времени (часто часов) требуется для выполнения пары десятков миллионов запросов. .. Bacula любит сравнительно немного больших файлов, иначе это собака.

Вы связаны с I / O. Ваша система - маленький спасательный плот, разбитый в штормовом море буферных / кэш / виртуальных пейджинговых волн высотой 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 там не является необычным. Если у вас есть несколько ядер или много мощностей шпинделя / шины для ввода / вывода, вы можете увеличить их (немного). Больше потоков очистки = больше операций ввода-вывода, но также больше процессорного времени, затраченного на ожидание ввода-вывода.

Это значение по умолчанию, или вы столкнулись с ним? Если вы столкнулись с этим, рассматривали ли вы вопрос об уменьшении числа, чтобы уменьшить количество нагрузок на операции ввода-вывода? Или у вас есть огромное количество шпинделей и каналов для работы, и в этом случае вы рассматривали возможность увеличения количества потоков очистки?

PS вы хотите установить swappiness на более низкие значения, а не на более высокие значения, чтобы предотвратить выгрузку. Самое высокое значение = 100 = поменять как сумасшедший, когда он чувствует себя хорошо, самое низкое значение = 0 = стараться вообще не менять.

Если вы посмотрите на блоки, считываемые за секунду (bi) при IO, то это значительно превосходит активность свопинга на несколько порядков. Я не думаю, что использование свопинга является причиной того, что ваш диск перебивает, я думаю, что у вас есть что-то работающее на коробке, которое просто вызывает большую активность диска (читает).

Я бы исследовал запущенные приложения и посмотрел, сможешь ли ты найти виновника.

Посмотрите, отвечает ли эта ссылка на некоторые ваши вопросы. Я регулярно вижу подкачку (не подкачку) памяти Linux задолго до 60% использования. Это ожидаемая часть настройки памяти:

http://www.sheepguardingllama.com/?p=2252

Но твоя нехватка буферов / кеша беспокоит меня. Это выглядит очень необычно. Поэтому я думаю, что что-то еще не так.

Можете ли вы попробовать отключить своп полностью?

swapoff /dev/hdb2

или что-то подобное - по крайней мере, это подтвердит, что это обмен, это ваша проблема, а не что-то еще.

По умолчанию swappiness установлено как 60.

cat / proc / sys / vm / swappiness 60

Swappiness - это ядро, используемое для настройки того, насколько ядро ​​предпочитает обмен по ОЗУ; высокая перестановка означает, что ядро ​​будет много менять, а низкая перестановка означает, что ядро ​​будет стараться не использовать пространство подкачки.

Мы можем изменить это редактирование значения vm.swappiness в /etc/sysctl.conf .

Вы можете вручную установить swappinness ядра, которое вы можете увидеть /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]', чтобы получить дополнительную информацию о памяти из некоторых более трудоемких процессов. Желаю тебе удачи!

Matt

Возможно, у вас есть недолговечные процессы, которые используют много памяти, а затем завершите работу, прежде чем вы сможете их заметить.

В любом случае это будет соответствовать тому, что вы видите.

Вы исследовали проблемы с кешем inode? slabtopдолжен хотя бы дать вам отправную точку, если вы столкнетесь с чем-то вроде этого.

В то время как ваша система является 64-битной, система может не справиться со всей доступной памятью. Это ограничение чипсета. Например, Mac mini предыдущего поколения «поддерживает» 4 ГБ ОЗУ, но только 3,3 ГБ было фактически адресуемым.