Постійне збільшення розміру свопів у Linux та Swap просторі не відшкодовується?


10

У мене є linux вікно оперативної пам'яті 8 Гб, на якому працює 4 сервери tomcat. Один з них встановлений на 3000 МБ пам'яті (jvm -Xms і -Xmx налаштування), а інші встановлені на 1500 МБ. Роздільний розділ також встановлено на 8 Gigs. Коли я запускаю ці сервери, використання файлів підкачки низьке. Але протягом періоду днів і протягом певного часу, коли один / усі сервери знаходяться в піковій активності, використання свопів починає зростати. Ось типовий вихід 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% swap, який використовується зараз. Найцікавіше, що це% НІКОЛИ не зменшується . Він продовжує зростати і сягає до 30-40% . Ми перезапускаємо наші сервери щотижня.

Я б припустив, що відсоток зросло збільшується в періоди пікової активності та зменшується в періоди низької активності. Або принаймні залишається постійним. Це виглядає так, що операційний простір ніколи не відновлюється.

Вихід безкоштовного: вільний -м загальний обсяг використаних безкоштовних загальних буферів, кешованих Mem: 7982 7937 45 0 32 2088 - / + буфери / кеш: 5816 2166 Зміна: 8191 1163 7028

Так що є щонайменше 2 г безкоштовного Рама. Отже, питання полягає в тому, чому простір підкачки продовжує збільшуватися і не повертається ОС? Або як налагодити це, щоб з'ясувати, що відбувається.

Відповіді:


12

Якщо інформація перекачується на диск і пізніше читається в пам'яті, вона часто залишатиметься виділеною в області підкачки, поки місця для заміни не вичерпаються. Це означає, що якщо ту саму інформацію потрібно пізніше замінити і не змінити, ОС може просто скинути сторінки з виділеної оперативної пам’яті, не потрібно нічого писати, щоб диск економив час.

Буде звільнено також і поміняння, що виділяється на речі, які були прочитані в пам'яті

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

Знайдіть /proc/meminfoрядок під назвою "SwapCched". Цей запис підраховує сторінки, які знаходяться як в оперативній пам'яті, так і в розділах swap. Наприклад, вибравши невеликий VM навмання, /proc/meminfoвіртуальний файл одного з моїх віртуальних машин показує:

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

що вказує на те, що виділено 74268 кб місця для заміни, але що ці сторінки в 17232 Кб також наразі відображені в оперативній пам’яті (тому можна було б перенести місце під час заміни, якщо проміжок потрібен чимось іншим).

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

Якщо ви хочете вияснити, що є в свопі, якщо у вас є достатня кількість вільних та / або безкоштовних (тобто вільний + кеш + буфери (за винятком тих частин рахунків c + b, які не є вільними RightThisInstant)), просто поверніть його вимкнути та знову знову з swapoff -a && swapon -a.

Звичайно, ви також могли десь витікати пам'ять, але це не єдине пояснення поведінки, яку ви бачите.


Відмінна відповідь. Дякую Таким чином, моя система наразі показує SwapTotal: 8388600 kB SwapFree: 7197688 kB SwapCaching: 595724 kB Отже, фактичний Swap Free = 7197688 + 595724 = 7793412. Actul Swap Used = 8388600 - 7793412 = 595188 == 581MB. Я думаю, що 581 Мб використання файлів підкачки є розумним для системи 8 ГБ із запущеними 4 додатками. Дозвольте мені контролювати це протягом наступних кількох днів і побачити, чи цифра swapCched продовжує збільшувати пропорційність до% swapUsed.
Зеніл

2

В основному, вам не потрібно про це дбати. Важливо знати, скільки IO йде на своп (дивіться команду 'vmstat'). Маючи більше речей у свопі, нічого не коштує. Єдина вартість - це помістити речі в своп (page in) або зняти його (page out). Тож цілком обґрунтовано, щоб ОС дозволяла заміні зростати.


1
Важливо знати, чому підміна росте і ніколи не зменшується. Що, якщо ми дозволимо нашим серверам продовжувати працювати тижнями? Чи зросте своп за межею і спричинить проблеми з пам'яттю? Зміна / заміни виглядає "розумною". У періоди пікової активності спостерігається високий обмін / своп (а також% збільшується). У звичайні періоди заміни / заміни мінімальні, але% заміни не зменшується
Zenil

0

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


0

Немає способу сказати, чи це врешті-решт стане проблемою, якщо ви не запустите сервер досить довго, щоб побачити, чи це стає проблемою.

В основному ОС буде міняти місцями, які не використовуються, щоб зберегти деяку кількість пам'яті, якщо ви запустили нову програму. Простір обміну не буде звільнено, поки це не знадобиться, це означає, що ви можете використовувати 100% місця для заміни та не мати проблем із продуктивністю. Варто турбуватися, якщо це спричинено витоком пам’яті. Це не обов'язково витік пам'яті, але це може бути.

Java не схильна до витоків пам'яті, але це може статися особливо зі складними програмами.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.