сбой распределения порядка 4 катастрофа

Сначала некоторые детали среды:

Оборудование:
Серверная плата Intel S2600GZ
2 процессора Intel Xeon E5-2620
64 ГБ оперативной памяти DDR3
RAID-контроллер Intel RS2BL (LSI SAS2108) с томом LVM 4 ТБ, сделанный из дисков SAS

Программное обеспечение:
Ubuntu 12.04.4 LTS / Linux 3.11.0-24-generic x86_64 (с последними обновлениями)
qemu / KVM (libvirt) с 6 виртуальными машинами (работает без проблем, несмотря на ситуацию)
сервер glusterfs 3.4.5 (вроде тоже нормально работает)
некоторые другие легкие софты (например, bind9, keepalived, openvpn и т. д.)
Нет нестандартное / экспериментальное / самодельное ПО!

Уже давно у нас есть очень странно проблема с одним из наших серверов Ubuntu: периодически он заполняет системный журнал сообщениями "сбой выделения", например:

Aug 28 07:00:18 srvname kernel: [4210234.157335] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:19 srvname kernel: [4210234.711173] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:20 srvname kernel: [4210235.938599] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:34 srvname kernel: [4210250.307283] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:51 srvname kernel: [4210267.170359] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:02 srvname kernel: [4210278.625530] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:19 srvname kernel: [4210295.671569] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0

Сообщения регистрируются примерно каждые 30 секунд, и они отражают реальную картину: процессы, показанные в этом фрагменте журнала, действительно не работают (например, агент zabbix не может передать данные на сервер zabbix). Но это лишь верхушка айсберга. Пока продолжается это истощение памяти любой процесс что нужно прочитать /proc каталог (например, ps, top, mpstat и т. д.) вылетает сразу после запуска, потому что не может его прочитать (/proc также не может быть указан вручную с помощью ls), и это событие немедленно записывается в системный журнал с той же ошибкой сбоя выделения 4-го порядка.

При этом свободной оперативной памяти (1/4 от общего объема) хватает, но если проверять по блокам - блоки 4-го порядка действительно исчерпаны. НО, чего я действительно не могу понять, так это ЗАЧЕМ эти процессы действительно запрашивают такие большие блоки? У нас есть еще один, практически идентичный (аппаратно и программно) сервер - его блоки 4-го порядка тоже исчерпаны - и вроде нормально, сбоев выделения 4-го порядка нет! Более того, этот идентичный сервер находится под МНОГО более тяжелая нагрузка.

Я много раз глубоко искал в Интернете симптомы «сбоев распределения (высокого порядка)», но, похоже, ничего не подходящее. Мы пробовали поиграть с различными параметрами sysctl (например, vm.min_free_kbytes, vm.vfs_cache_pressure и т. д., как предлагают некоторые статьи), но ничего не помогает. В конце концов мы отменили все эти изменения, и теперь большинство настроек sysctl являются системными по умолчанию. Мы также пробовали echoвход в /proc/sys/vm/compact_memory и /proc/sys/vm/drop_caches без явного (или длительного) эффекта. После некоторого длительного периода истощения, внезапно и само по себе все становится нормально (похоже, что память дефрагментируется и становятся доступными порядка 4 блоков, /proc становится доступным тоже), но ненадолго - через небольшой промежуток времени все начинается сначала. Перезагрузка помогает дольше (из-за полностью нефрагментированной памяти), но в конечном итоге все заканчивается так же ...

В общем, единственные настоящие беды (что мы осведомленный of), вызванная описанным поведением, заключается в невозможности контролировать ресурсы сервера и управлять ими ни удаленно (zabbix), ни локально (ps, top, mpstat и т.д.).

Насколько я понимаю, отсутствие блоков порядка 4 - это нормальное нормальное состояние памяти под Linux. Просто процессы, как правило, не должны запрашивать такие блоки (особенно процессы, которые НЕ сделайте это на других серверах). Если кто-нибудь знает, что может быть причиной такого поведения, что мы можем проверить или где копать - мы были бы очень признательны! Мы готовы предоставить любую дополнительную информацию по запросу.