У меня огромная проблема с кэшем страниц Linux, который замедляет ввод-вывод. Например, если я копирую раздел lvm с помощью dd, Linux кэширует данные в буферах или кэшах (free –m). Проблема не в этом, но после того, как буфер достигает определенного значения, процесс копирования останавливается и замедляется до нескольких мегабайт или даже килобайт. Я провел много тестов с записью на диск или /dev/null, проблема не имеет ничего общего с исходным диском или местом назначения.
В деталях:
- Есть два почти идентичных сервера. Оба работают под управлением CentOS 6.5 с одинаковым ядром. У них одинаковые диски, одинаковые настройки, одинаковое остальное оборудование, одинаковые во всех отношениях. Единственное отличие в том, что у одного сервера 2 ЦП и 64 ГБ ОЗУ, а у другого — 1 ЦП и 32 ГБ ОЗУ.
- Вот также изображение следующего процесса копирования:https://i.stack.imgur.com/tYlym.jpg
- Вот новая версия также с meminfo. Meminfo из другого запуска, поэтому значения не идентичны, но это полностью то же самое поведение:https://i.stack.imgur.com/4SIJG.jpg
- Начните копирование с помощью dd или другой программы копирования файловой системы.
- Буфер или кэш начинают заполняться. Все в порядке.
- Буфер или кэш достигает максимального значения (на сервере с 64 ГБ оперативной памяти значение может быть равно 32 ГБ или 17 ГБ; на сервере с 32 ГБ оперативной памяти вся память свободна)
- На сервере с 64 ГБ оперативной памяти процесс копирования теперь останавливается или ограничивается несколькими МБ. На сервере с 32 ГБ оперативной памяти все в порядке.
- На сервере с 64 ГБ оперативной памяти я могу решить проблему на короткое время, принудительно задействовав кэш с помощью "sync; echo 3 > /proc/sys/vm/drop_caches". Но, конечно, буфер начинает мгновенно расти снова, и проблема возникает снова.
Заключение:
Проблема либо как-то связана со вторым процессором, либо с общим объемом памяти. У меня есть «чувство», что проблема может быть в том, что у каждого процессора есть свои 32 ГБ оперативной памяти, и процесс копирования выполняется только на процессоре. Итак, в конце концов, процесс копирования увеличил буфер / кэш почти до 32 ГБ или до неиспользуемой памяти другого процессора, а затем Linux думает: «Эй, память еще есть, поэтому давайте увеличим буфер еще больше, но оборудование ниже не может получить доступ к памяти», или что-то в этом роде.
Есть ли у кого-нибудь идея или решение?Конечно, я могу использовать dd с прямым флагом, но это не решит проблему, потому что есть также внешний доступ через Samba и т. д.
ПРАВКА1:
Вот также /proc/zoneinfo с сервера с 64 ГБ оперативной памяти: 1.http://pastebin.com/uSnpQbeD(до начала dd) 2.http://pastebin.com/18YVTfdb(когда dd перестанет работать)
ПРАВКА2:
- Настройки виртуальной машины:http://pastebin.com/U9E9KkFS
- /proc/sys/vm/zone_reclaim_mode был на сервере 0 с 32 ГБ оперативной памяти и на сервере 1 с 64 ГБ оперативной памяти. Я никогда не трогал эти значения. Их установил установщик. Я временно изменил его на 0 и повторил тест. Теперь вся память используется для буфера и кэша. Так что все выглядит отлично и похоже на другой сервер. Но затем он мгновенно начинает подкачку на полной скорости... Я установил swapiness на 0. Это помогло, но он все еще подкачивает несколько МБ в секунду. И он увеличивает буферы каждую секунду. Так что он не подкачивает буфер, он подкачивает память vms, чтобы получить больше памяти для увеличения буферов... безумие. Но, может быть, это нормально!?
РЕДАКТИРОВАНИЕ3:
/proc/buddyinfo и numactl --hardware: http://pastebin.com/0PmXxxin
КОНЕЧНЫЙ РЕЗУЛЬТАТ
- /proc/sys/vm/zone_reclaim_mode — это, конечно, технически правильный способ, но машина после этого работала не очень хорошо. Например: если я копирую диск, Linux теперь использует 100% свободной памяти для буферизации (а не как раньше, только XGB, а затем останавливается). Но во-вторых, при этом последняя свободная память использовалась для буферизации, Linux начинает подкачку памяти виртуальной машины и увеличивает общий объем буфера и кэшей. Подкачка обычно не нужна в моей системе, поэтому память подкачки находится на том же диске, что и некоторые виртуальные машины. В результате, если сделать резервную копию этих виртуальных машин, Linux записывает подкачку в то же время, когда я читаю с диска для резервной копии. Так что плохо менять vms, но еще хуже, что linux уничтожает мою скорость чтения резервной копии... Так что установка /proc/sys/vm/zone_reclaim_mode в 0 не решает проблему полностью... в настоящее время я запускаю на экране скрипт, который синхронизируется и очищает кэш каждые 10 секунд... не очень хорошо, но для меня работает намного лучше. У меня нет веб-сервера или обычного файлового сервера в системе. Я запускаю только vms, делаю резервные копии и храню резервные копии через samba. Мне не нравится это решение.
решение1
Наблюдаемое вами поведение обусловлено способом, которым Linux выделяет память в системе NUMA.
Я предполагаю (не зная наверняка), что система на 32 ГБ не является системой NUMA или не обладает достаточной NUMA-функциональностью, чтобы Linux мог ею интересоваться.
Поведение того, как работать с numa, определяется опцией /proc/sys/vm/zone_reclaim_mode. По умолчанию linux определит, используете ли вы систему numa, и изменит флаги возврата, если посчитает, что это даст лучшую производительность.
Память разделена на зоны, в системе numa есть зона для первого сокета ЦП и зона для второго. Они появляются как node0и node1. Вы можете увидеть их, если вы cat /proc/buddyinfo.
Когда режим восстановления зоны установлен на 1, выделение из первого сокета ЦП приведет к восстановлению зоны памяти, связанной с этим ЦП, это происходит потому, что восстановление из локального узла numa более эффективно с точки зрения производительности. Восстановление в этом смысле означает сброс страниц, например, очистку кэша или подкачку чего-либо на этом узле.
Установка значения 0 приводит к тому, что при заполнении зоны не происходит никаких возвратов, вместо этого выделяются внешние зоны numa для памяти. Это происходит за счет кратковременной блокировки другого ЦП для получения эксклюзивного доступа к этой зоне памяти.
Но затем он мгновенно начинает подкачку! через несколько секунд: Память: всего 66004536 КБ, используется 65733796 КБ, свободно 270740 КБ, буферы 34250384 КБ Подкачка: всего 10239992 КБ, используется 1178820 КБ, свободно 9061172 КБ, кэшировано 91388 КБ
Поведение подкачки и время подкачки определяются несколькими факторами, одним из которых является активность страниц, выделенных приложениям. Если они не очень активны, они будут подкачаны в пользу более загруженной работы, происходящей в кэше. Я предполагаю, что страницы в ваших виртуальных машинах активируются не очень часто.