Перенесено из bug #28038 то, что к 28038 не относится. Comment #8 From Vitaly Lipatov 2015-01-13 18:43:59 (-) [reply] (В ответ на комментарий №7) > Я его втащил, т.к. столкнулся с падениями collectd и лучше без дополнительных > зависимостей. Спасибо, но сейчас у нас а) collectd жутко течёт б) не прибивается через /etc/init.d/collecd stop (порождённый процесс collectd -f не завершается) в) когда каждая программа начинает сама следить за собой, да ещё и неумело, получается ужасный зоопарк. Я уже понял, что сбежать получится только в systemd. Как бы ни хотелось. ============================================ Comment #9 From Anton Farygin 2015-01-13 18:45:19 (-) [reply] Виталь, а где у тебя collectd жутко течёт ? У меня collectd из Sisyphus работает месяцами без проблем. Может быть, для начала - обновим его, потом апстрим попинаем на предмет утечек ? ============================================ этот комментарий касается 5.2.1 (кажется) Comment #12 From Vitaly Lipatov 2015-01-14 14:39:27 (-) [reply] Путём исключения выяснили, что нужен настроенный LoadPlugin mysql чтобы началась утечка. Возможно, его просто никто не использует :) ============================================ Comment #18 From Sergey Y. Afonin 2015-01-16 10:26:28 (-) [reply] (In reply to comment #12) > Путём исключения выяснили, что нужен настроенный > LoadPlugin mysql > чтобы началась утечка. Не только. Я смотрел 5.4.1 в прошлом году, вот тут кое-что написано: http://lists.altlinux.org/pipermail/sysadmins/2014-June/036828.html http://lists.altlinux.org/pipermail/sysadmins/2014-July/036835.html В моей конфигурации много собирается по snmp. В итоге, я откатился на 5.2.1 после того эксперимента. Сейчас попробую обновиться из задания 138515. ============================================ Comment #20 From Sergey Y. Afonin 2015-01-21 08:46:42 (-) [reply] (In reply to comment #15) > Собрал под p7, проверил, течь перестало: > [#138515] p7 EPERM collectd.git=5.4.1-alt1.M70P.2.1 Течёт: Mon Jan 19 15:35:03 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756588 114736 5404 S 5,319 0,620 3:29.69 collectd Tue Jan 20 09:34:59 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756880 712384 5404 S 2.992 3.851 125:34.02 collectd Wed Jan 21 09:36:57 SAMT 2015: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19356 root 20 0 3756588 1.437g 5436 S 8.976 8.144 291:34.52 collectd Используемые у меня плагины: LoadPlugin syslog LoadPlugin cpu LoadPlugin interface LoadPlugin load LoadPlugin memory LoadPlugin network LoadPlugin rrdtool LoadPlugin sensors LoadPlugin snmp LoadPlugin match_regex LoadPlugin match_value LoadPlugin match_timediff LoadPlugin target_notification LoadPlugin target_replace LoadPlugin target_set 5.2.1 не течёт в таком же режиме работы.
Сергей, а каким образом systemd поможет избежать утечек ? пункт б у меня не воспроизводится: [root@ ~]# ps aux|grep collectd root 28675 0.0 0.0 4228 260 ? Ss 18:20 0:00 /usr/sbin/collectdmon root 28678 0.2 0.1 961364 6184 ? Sl 18:20 0:00 collectd -f root 28717 0.0 0.0 6960 640 pts/0 S+ 18:20 0:00 grep --color=auto collectd [root@ ~]# rpm -q collectd collectd-5.4.1-alt2.1 [root@bridge ~]# /etc/init.d/collectd stop Stopping collectdmon service: [ DONE ] [root@ ~]# ps aux|grep collectd root 28740 0.0 0.0 6960 640 pts/0 S+ 18:20 0:00 grep --color=auto collectd [root@ ~]# /etc/init.d/collectd start Starting collectdmon service: [ DONE ] [root@ ~]# ps aux|grep collectd root 28780 0.0 0.0 4228 264 ? Ss 18:20 0:00 /usr/sbin/collectdmon root 28783 1.5 0.1 961364 4096 ? Sl 18:20 0:00 collectd -f root 28801 0.0 0.0 6960 644 pts/0 S+ 18:20 0:00 grep --color=auto collectd
Что касается утечки - опишите плз, что нужно минимальное сделать на свежеустановленной системе, что бы воспроизвести утечку памяти ?
и ещё, если отключить snmp - утечки исчезают ?
(In reply to comment #1) > Сергей, а каким образом systemd поможет избежать утечек ? Баг к systemd отношения, как раз, не имеет, потому и заведён отдельно от bug #28038. Вопросами, как воспроизвести, и какой именно плагин течёт, пока не занимался. snmp-плагин отключить не могу на долго - данные нужны, так что надо где-то отдельно поставить.
просьба проверить, я хочу научиться воспроизводить у себя локально.
Вот тут ищут тестеров, которые поучавствуют в исправлении утечек памяти collectd. Нет желания присоединиться ? http://mailman.verplant.org/pipermail/collectd/2015-January/006433.html
В общем вот: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16/02/15 15:10 7853 root 20 0 865648 31788 17076 S 0.000 1.236 0:01.15 collectd 16/02/15 17:42 7853 root 20 0 865912 32604 17080 S 0.000 1.268 1:31.86 collectd 18/02/15 01:48 7853 root 20 0 866308 33680 16324 S 0.332 1.309 17:52.13 collectd 19/02/15 10:07 7853 root 20 0 866704 35572 16324 S 2,320 1,383 33:53.25 collectd Это после подключения snmp-плагина и включения сбора данных по трафику с 48 портового коммутатора.
(In reply to comment #7) > Это после подключения snmp-плагина и включения сбора данных по трафику с 48 > портового коммутатора. Хм. 27/02/15 7853 root 20 0 868948 18104 1344 S 0,000 0,704 130:41.56 collectd В какой-то момент, получается, память освободилась. Непонятно. И появилось подозрение, что ещё и bind-плагин течёт, но это я совсем долго проверять буду. Кстати, 5.4.2 зарелизилась, надо с ней проверить, может рассосётся проблема.
> Кстати, 5.4.2 зарелизилась, надо с ней проверить, может > рассосётся проблема. Из журнала изменений: RRDtool and RRDCacheD plugins: A memory leak when creating RRD files has been fixed. Thanks to Yves Mettier. #661 SNMP plugin: Fix a memory leak. Thanks to Marc Fournier and Pierre-Yves Ritschard. #610, #804 Так что да, нужно уже новую версию тестить.
(In reply to comment #9) > RRDtool and RRDCacheD plugins: A memory leak when creating RRD files has been > fixed. Thanks to Yves Mettier. #661 О как. А вот на них я вообще не думал. Там, где подозрение на bind, отключил rrd - всё равно там на центральный сервер льётся. Может, тогда, и не bind.
Для тех, кто хочет побыстрее: http://git.altlinux.org/tasks/archive/done/_137/141129/ Всем остальным ждать завтрашнего сизифа.
Вроде как, стало заметно лучше: 07/03/15 17:20 9520 root 20 0 3758748 104024 5404 S 3,324 0,562 2:13.06 collectd 09/03/15 16:19 9520 root 20 0 3758748 111660 5444 S 4,654 0,604 348:25.76 collectd Это та же самая система, которая упомянута в исходном сообщении тут и в 20-ом комментарии к bug #28038. Так что, наверное, можно готовить обновление collectd в t7
