Подкачка, используемая сообщаемый свободным, очень высока.
[root@rhel6 ~]# free -m
total used free shared buffers cached
Mem: 9892 9537 354 0 71 884
-/+ buffers/cache: 8581 1310
Swap: 767 1759218592 116869
Как, действительно высоко.
[root@bb14 blackboard]# free -g|grep Swap
Swap: 0 1717986906 114
Или это?
[root@bb14 blackboard]# free -h |grep Swap
Swap: 767M 767M 114G
Еще более странный, даже если я отключаю, подкачивают число, все еще остается высоким.
[root@rhel6 ~]# swapoff -a
[root@rhel6 ~]# free -m
total used free shared buffers cached
Mem: 9892 9760 131 0 45 638
-/+ buffers/cache: 9076 815
Swap: 0 1759218592 116814
Вещи не становятся немного менее сбивающими с толку при проверке meminfo, который показывает swapfree выше, чем swaptotal.
[root@rhel6 ~]# cat /proc/meminfo|grep Swap
SwapCached: 0 kB
SwapTotal: 786428 kB
SwapFree: 120404008 kB
Очевидно, что-то - wonky, и мой первый инстинкт должен перезагрузить, но это - производственная машина, что означает окна обслуживания, и т.д., и я задаюсь вопросом, существует ли какой-либо способ узнать что случилось и возможно даже зафиксировать его без времени простоя.
Решением было обновление до ядра-2.6.32-573.7.1.el6 или выше.
Простое юм-обновление
и перезагрузка должны быть всем, что нужно.
Ниже приведена цитата из сообщения об ошибке ядра-2.6.32-573.1.1.el6.x86_64, которая привела к тому, что количество Свопов больше, чем общее количество Свопов:
Предыдущее изменение в блокировке get_swap_page() удалило использование функции swap_lock spinlock. Это может привести к повреждению nr_swap_pages и недействительная информация swapFree в файле /proc/meminfo, где размер СвопФри может превысить размер СвопТотала. В данном обновлении используется атомарная переменная для nr_swap_pages, и размер SwapFree в /proc/meminfo теперь верно. (BZ#1259362)
Похоже, это известная проблема в RHEL6 .7 с kernel-2.6.32-573.1.1.el6.x86_64, отслеживаемым в их частной bugzilla.