Постоянно увеличивающийся размер подкачки в Linux и пространство подкачки не восстанавливается?

У меня есть 8 ГБ ОЗУ Linux, на котором работают 4 сервера Tomcat. Один из них установлен на 3000 МБ памяти (jvm -Xms и -Xmx), а другие на 1500 МБ. Раздел подкачки также установлен на 8Gigs. Когда я запускаю эти серверы, использование файла подкачки низкое. Но в течение нескольких дней и в определенные моменты, когда один / все серверы находятся в пиковой активности, использование свопа начинает увеличиваться. Вот типичный вывод sar -r.

kbmemfree kbmemused% memused kbbuffers kbcached kbswpfree kbswpused % swpused kbswpcad

48260 8125832 99,41 196440 2761852 7197688 1190912 14,20 316044

75504 8098588 99.08 198032 2399460 7197688 1190912 14.20 316032

Это показывает 14,2% своп, используемый в настоящее время. Самое смешное, что этот% НИКОГДА не уменьшается . Продолжает расти и доходить до 30-40% . Мы перезапускаем наши серверы еженедельно.

Я бы предположил, что % swpused увеличивается в периоды пиковой активности и уменьшается в периоды низкой активности. Или, по крайней мере, остается постоянным. Похоже, что пространство подкачки никогда не возвращается ОС.

Вывод free: free -m всего использованных свободных общих буферов, кэшированных. Mem: 7982 7937 45 0 32 2088 - / + буферов / кэш: 5816 2166 Swap: 8191 1163 7028

Так что есть как минимум 2 г бесплатного барана. Таким образом, вопрос в том, почему пространство подкачки продолжает увеличиваться и не используется ОС? Или как отладить это, чтобы выяснить, что происходит ..

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

Своп, выделенный для материала, который был считан обратно в память, также будет освобожден

1. когда соответствующие страницы больше не нужны (т.е. освобождаются приложением)
2. когда соответствующие страницы изменены (поэтому копия на диске больше не актуальна)
3. у машины мало места подкачки, поэтому очищает некоторые вещи, которые уже находятся в оперативной памяти, чтобы освободить место

Найдите /proc/meminfoстроку под названием «SwapCached». Эта запись подсчитывает количество страниц, найденных как в оперативной памяти, так и в разделах подкачки. Например, при случайном выборе небольшой виртуальной машины /proc/meminfoодин из моих виртуальных файлов показывает:

SwapTotal:        698816 kB
SwapFree:         624520 kB
SwapCached:        17232 kB

указывает, что выделено 74268 КБ пространства подкачки, но эти страницы на 17232 КБ также в настоящее время также отображаются в ОЗУ (так что может быть освобождено из раздела подкачки в любой момент, если пространство требуется для чего-то другого).

Также не будет сомнений в том, что там были страницы, которые были заменены много лет назад и с тех пор никогда не использовались. Ядро не будет перезагружать страницы из подкачки только потому, что есть некоторая свободная оперативная память для чтения ее обратно, так как эта свободная оперативная память может лучше использоваться для кеша или буферов - страницы, записанные для подкачки, обычно перечитываются только тогда, когда они необходимы в следующий раз.

Если вы хотите выяснить, что находится в разделе подкачки, при условии, что у вас достаточно свободных и / или свободных (т. Е. Free + cache + buffers (за исключением тех частей числа c + b, которые не являются доступными RightThisInstant)), просто включите его выключить и снова включить с swapoff -a && swapon -a.

Конечно, у вас также может быть утечка памяти, но это не единственное объяснение поведения, которое вы наблюдаете.

По сути, вам не нужно заботиться об этом. Важно знать, сколько IO идет на подкачку (посмотрите на команду 'vmstat'). Наличие большего количества вещей в свопе ничего не стоит. Единственная цена - это положить что-то в своп (страница в) или вынуть (страница). Поэтому для ОС вполне разумно позволить расширению свопа.

до тех пор, пока у вас есть доступное пространство подкачки, ОС не нужно освобождать пространство подкачки. Он будет освобожден, когда не останется места. Но когда вы попадаете в эту ситуацию, у вас точно есть проблема.

Невозможно определить, станет ли это в конечном итоге проблемой, если вы не запустите сервер достаточно долго, чтобы посмотреть, не станет ли это проблемой.

По сути, операционная система будет заменять вещи, которые не используются, для постоянного сохранения некоторой памяти в случае запуска новой программы. Пространство подкачки не будет освобождено до тех пор, пока оно не потребуется, а это означает, что вы можете использовать пространство подкачки на 100% без проблем с производительностью. О чем стоит беспокоиться, если это вызвано утечкой памяти. Это не обязательно утечка памяти, но может быть.

Java не подвержена утечкам памяти, но это может случиться со сложными приложениями, особенно.