Утечка памяти? РЕЛ 5.5. RSS показывает нормально, свободной памяти почти не осталось, swap интенсивно используется
Я сталкиваюсь с очень интересной проблемой, и кажется, что некоторые физические могут спокойно расстроиться. Я очень озадачен, поэтому, если кто-нибудь сможет оказать некоторую помощь, я буду очень признателен.
вот мое лучшее шоу:
сортировать по использованию памяти Процессор (ы): 0,8% США, 1, 0%sy, 0, 0% ni, 81,1% id, 14,2% wa, 0, 0% hi, 2,9% si, 0, 0% st Память: всего 4041160 КБ, использовано 3947524 КБ, 93636 КБ свободно, буферы 736 КБ. Обмен: всего 4096536 КБ, использовано 2064148 КБ, 2032388 КБ свободно, кэшировано 41348 КБ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ КОМАНДА 15168 корень 20 0 3127 м 290 м 1908 S 108,2 7,4 43376:10 STServer-1 18303 корень 20 0 99,7 м 12 м 912 с 0, 0 0, 3 0: 00,86 сшд 7129 корень 20 0 17160 7800 520 S 0,5 0,2 5: 37,52 thttpd 2583 корень 10 -10 4536 2488 1672 S 0, 0 0,1 1: 19, 33 iscsid 4360 корень 20 0 15660 2308 464 S 0, 0 0,1 15: 42,71 lbtcpd.out 4361 корень 20 0 186 м 1976 964 S 0,5 0, 0 82: 00, 36 lbsvr.out 3932 корень 20 0 100 м 1948 836 S 0, 0 0, 0 30: 31, 38 snmpd 18604 root 20 0 66212 1184 820 S 0, 0 0, 0 0: 00, 06 bash 18305 корень 20 0 66112 1136 764 S 0, 0 0, 0 0: 00, 03 bash 18428 корень 20 0 12924 1076 708 R 1, 0 0, 0 0: 21,10 верх 15318 корень 20 0 99,7 м 1020 996 S 0, 0 0, 0 0: 01,15 sshd 15320 корень 20 0 66228 996 788 S 0, 0 0, 0 0: 00,80 bash 1719 корень 20 0 90216 980 884 S 0, 0 0, 0 0: 02,29 sshd 15492 корень 20 0 66216 972 780 S 0, 0 0, 0 0: 00,20 Bash 15382 root 20 0 90300 964 892 S 0, 0 0, 0 0: 00,57 sshd 1688 корень 20 0 90068 960 852 S 0, 0 0, 0 0: 00,57 sshd 2345 корень 20 0 90068 928 852 S 0, 0 0, 0 0: 00,50 sshd 16175 корень 20 0 90216 924 884 S 0, 0 0, 0 0: 00,64 sshd 2377 корень 20 0 90068 908 852 S 0, 0 0, 0 0: 00,44 sshd 2725 корень 20 0 90216 896 884 S 0, 0 0, 0 0: 05,27 sshd 3929 root 20 0 182m 896 816 S 0, 0 0, 0 0: 43,61 systemInfoSubAg 15986 root 20 0 66216 884 772 S 0, 0 0, 0 0: 00, 03 bash
и вот мои бесплатные шоу:
[root @ ric ~] # free -m
общее количество использованных свободных общих буферов в кеше
Память: 3946 3846 100 0 0 48
-/+ буферы / кэш: 3796 149
Обмен: 4000 2037 1963
вот мой iostat показывает:
[root @ ric ~] # iostat -x -d -m 2 Linux 2.6.37 (ric) 16.08.2011 Устройство: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sda 93,24 222,57 95,44 64,40 4,10 1,12 66,96 1, 37 25,46 2,78 44,44 sda1 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 40,80 0, 00 4, 00 3,10 0, 00 sda2 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 22, 35 0, 00 22,52 14,80 0, 00 sda4 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 2, 00 0, 00 33, 00 33, 00 0, 00 sda5 92,73 7,49 53, 39 45,79 0,57 0,21 16, 08 0,72 34,67 3,19 31,67 sda6 0,50 215, 08 42, 06 18,61 3,53 0,91 150,14 0,65 55,27 6, 36 38,58 Устройство: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sda 596, 02 139, 30 248,26 153,73 3, 38 1,14 23, 02 147,54 482,67 2,49 99,90 sda1 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda2 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda4 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda5 596, 02 129, 35 244,28 150,25 3, 30 1, 09 22,79 146,51 488,14 2,53 99,90 это раздел подкачки sda6 0, 00 9,95 3,98 3,48 0, 08 0, 05 35,20 1, 03 193,60 75,20 56,12
какой-то номер достался из / proc / meminfo
MemTotal: 4041160 kB
MemFree: 130288 kB
Buffers: 820 kB
Cached: 40940 kB
SwapCached: 82632 kB
SwapTotal: 4096536 kB
SwapFree: 2005408 kB
uname -a показывает: Linux ric 2.6.37 #4 SMP пт 14 января 10:23:46 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
мы можем обнаружить, что своп fs интенсивно используется. И это потребляет много ресурсов ввода-вывода. но когда мы берем верхнюю часть RSS-колонки, мы обнаруживаем, что сумма всех процессов RES не слишком велика.
поэтому мой вопрос: это утечка уровня ядра? или что-то не так с процессом STServer-1? (STServer использует пул momery для кэширования файловых данных, которые были выгружены из-за отсутствия использования в течение нескольких дней).
Любой комментарий приветствуется. Спасибо!
Udpate 1, slabtop показывает
Активные / Всего объектов (использовано%): 487002/537888 (90,5%) Активные / Всего слэбы (использовано%): 39828/39873 (99,9%) Активно / Всего кэшей (использовано%): 102/168 (60,7%) Активно / Общий размер (использованный%): 145605, 37 КБ / 154169,46 КБ (94,4%) Минимальный / Средний / Максимальный объект: 0, 02 КБ / 0,29 К / 4096, 00 КБ ОБЪЕКТЫ АКТИВНОЕ ИСПОЛЬЗОВАНИЕ ОБЗОРНЫЕ КАРТЫ РАЗМЕРА OBJ / ИМЯ КАБЕЛЯ КЛАБА 133920 133862 99% 0.02K 930 144 3720K avtab_node 98896 94881 95% 0, 03K 883 112 3532K размер-32 74052 73528 99% 1, 00K 18513 4 74052K размер-1024 72112 70917 98% 0,44K 9014 8 36056K skbuff_fclone_cache ...
обновление 2, добавление результатов pmap -x 15168 (STServer-1)
0000000000881000 45116 17872 17272 rw--- [ anon ] 00000000403a1000 4 0 0 ----- [ anon ] 00000000403a2000 8192 8 8 rw--- [ anon ] ... 00000000510aa000 4 0 0 ----- [ anon ] 00000000510ab000 8192 0 0 rw--- [ anon ] ... до 32 8192 00007f8f2c000000 9832 4004 3964 rw --- [anon] 00007f8f2c99a000 55704 0 0 ----- [anon] 00007f8f34000000 11992 5068 5032 rw --- [anon] 00007f8f34bb6000 53544 0 0 ----- [anon] 00007f8f38000000 9768 4208 4164 rw --- [anon] 00007f8f3898a000 55768 0 0 ----- [anon] 00007f8f3c000000 13064 4080 4024 RW --- [anon] 00007f8f3ccc2000 52472 0 0 ----- [anon] 00007f8f40000000 11244 3700 3688 rw --- [anon] 00007f8f40afb000 54292 0 0 ----- [anon] 00007f8f44000000 11824 7884 7808 rw --- [anon] 00007f8f44b8c000 53712 0 0 ----- [anon] 00007f8f4c000000 19500 6848 6764 rw --- [anon] 00007f8f4d30b000 46036 0 0 ----- [anon] 00007f8f54000000 18344 6660 6576 rw --- [anon] 00007f8f551ea000 47192 0 0 ----- [anon] 00007f8f58774000 1434160 0 0 rw --- [anon] пул памяти 00007f8fb0000000 64628 32532 30692 rw --- [anon] 00007f8fb7dfe000 1028 1016 1016 rw --- [anon] 00007f8fb8000000 131072 69512 65300 rw --- [anon] 00007f8fc0000000 65536 52952 50220 rw --- [anon] 00007f8fc40a8000 3328 1024 1024 rw --- [anon] 00007f8fc4aa5000 1028 1028 1028 rw --- [anon] 00007f8fc4d12000 1028 1020 1020 rw --- [anon] 00007f8fc4f15000 2640 988 936 rw --- [anon] 00007f8fc53b6000 2816 924 848 rw --- [anon] 00007f8fc5bf6000 102440 0 0 rw --- [anon] всего кБ 3202160 348944 327480
кажется, что ядро меняет старую память (не использовавшуюся в течение нескольких дней) для замены раздела, но частной памяти не так уж много. если у этой программы утечка памяти, то где она? в обмен? в RSS?
обновление 3, убить STServer-1 Я пытаюсь убить процесс STServer-1. использование free -m для проверки физической памяти. но осталось еще не так уж много. осталось около 400МБ. нет кеша, нет буфера еще. Я пишу небольшую программу для выделения памяти, она может запросить только 400 МБ физической памяти, после чего своп снова будет интенсивно использоваться.
так я должен сказать, что есть утечка памяти ядра?
обновление 4, это случилось снова! вот grep ^VmPea /proc/*/status | сортировка -n -k+2 | хвост показывает:
/ proc / 3841 / статус:VmPeak: 155176 кБ / proc / 3166 / статус:VmPeak: 156408 кБ / proc / 3821 / статус:VmPeak: 169172 кБ / proc / 3794 / статус:VmPeak: 181380 кБ / proc / 3168 / статус:VmPeak: 210880 кБ /proc/3504/status:VmPeak: 242268 кБ / proc / 332 / статус:VmPeak: 254184 кБ /proc/5055/status:VmPeak: 258064 кБ / proc / 3350 / статус:VmPeak: 336932 кБ / proc / 28352 / статус:VmPeak: 2712956 кБ
лучшие шоу:
Задачи: всего 225, 1 работает, 224 спит, 0 остановлен, 0 зомби ЦП: 1,9% сша, 1, 3% с.и., 0, 0% н.и., 51,9% id, 43,6% у.а., 0, 0% hi, 1, 3% с.и., 0, 0% st Память: всего 4041160 тыс., Использовано 3951284 тыс., Свободно 89876 тыс., Буферы 1132 тыс. Обмен: всего 4096536 КБ, использовано 645624 КБ, 3450912 КБ свободно, кэшировано 382088 КБ. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ КОМАНДА 28352 корень 20 0 2585 м 1,6 г 2320 D 52,2 42,7 267: 37,28 STServer-1 3821 фырканье 20 0 165м 8320 3476 S 10,2 0,2 1797: 20 фырканье 21043 корень 20 0 17160 7924 520 S 0, 0 0,2 1: 50,55 thttpd 2586 корень 10 -10 4536 2488 1672 S 0, 0 0,1 0: 28,59 iscsid
iostat показывает:
Устройство: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sda 72,50 0, 00 351, 00 2,50 12,25 0, 01 71, 02 174,22 213,93 2,83 100,20 sda1 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda2 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda4 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 0, 00 sda5 64, 00 0, 00 50, 00 0, 00 0,43 0, 00 17,76 76, 06 59,44 20, 04 100,20 раздел подкачки sda6 8,50 0, 00 301, 00 2,50 11,81 0, 01 79,79 98,16 239, 39 3, 30 100,20
любая идея??
2 ответа
Проверьте VmPeak из /proc:
$ grep ^VmPea /proc/*/status | sort -n -k+2 | tail
/proc/32253/status:VmPeak: 86104 kB
/proc/5425/status:VmPeak: 86104 kB
/proc/9830/status:VmPeak: 86200 kB
/proc/8729/status:VmPeak: 86248 kB
/proc/399/status:VmPeak: 86472 kB
/proc/19084/status:VmPeak: 87148 kB
/proc/13092/status:VmPeak: 88272 kB
/proc/3065/status:VmPeak: 387968 kB
/proc/26432/status:VmPeak: 483480 kB
/proc/31679/status:VmPeak: 611780 kB
Это должно показать, какой pid пытался использовать больше всего ресурсов виртуальной машины и должен указывать на источник использования. Если вы не видите большого объема памяти в этом списке, вам нужно взглянуть на остальные числа в /proc/meminfo.
Top не показывает системную память, и вы, возможно, используете слишком много памяти, если вы не настроили сетевые буферы для своего варианта использования.