Трафик

[Gosha]

А позвольте спросить NodenY45 . У Вас есть разделение мира и Украины? Просто за последние месяцы в три раза вырос файлик украинских сетей. Кстати на nodeny 50 эту проблему обсуждают.

Разделение есть, да вырос, около 60к префиксов приходит, но опять же вопрос в том что все было нормально даже тогда когда выросло их кол-во.

А какое значение  у Вас max_connections в mysql ?

[NodenY45]

А позвольте спросить NodenY45 . У Вас есть разделение мира и Украины? Просто за последние месяцы в три раза вырос файлик украинских сетей. Кстати на nodeny 50 эту проблему обсуждают.

Разделение есть, да вырос, около 60к префиксов приходит, но опять же вопрос в том что все было нормально даже тогда когда выросло их кол-во.

А какое значение  у Вас max_connections в mysql ?

Код:

mysql> show variables like "max_connections";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

[Gosha]

max_connections=500

т.е. увеличим максимально возможное количество одновременных соединений с mysql. Дело в том, что в момент наступления нового месяца запускается скрипт, который проводит снятия со счетов абонентов, обнуляет трафик и выполняет др. сервисные функции. В этот период любопытство клиентов достигает максимального уровня и большое их количество открывает Web-статистику дабы выяснить, что же произошло с их счетом. При этом организуется большое количество соединений с mysql, что может негативно сказаться на работоспособности скрипта «перехода на новый месяц». Значение 500 подобрано для сети с 20 тыс абонентов и имеет значительный запас.

Это для nodeny50 . Возможно имеет смысл тоже повысить. Ведь обсчет направлений(а их много) тоже увеличивает количество соединений с mysql.

[NodenY45]

max_connections=500

т.е. увеличим максимально возможное количество одновременных соединений с mysql. Дело в том, что в момент наступления нового месяца запускается скрипт, который проводит снятия со счетов абонентов, обнуляет трафик и выполняет др. сервисные функции. В этот период любопытство клиентов достигает максимального уровня и большое их количество открывает Web-статистику дабы выяснить, что же произошло с их счетом. При этом организуется большое количество соединений с mysql, что может негативно сказаться на работоспособности скрипта «перехода на новый месяц». Значение 500 подобрано для сети с 20 тыс абонентов и имеет значительный запас.

Это для nodeny50 . Возможно имеет смысл тоже повысить. Ведь обсчет направлений(а их много) тоже увеличивает количество соединений с mysql.

Сделал, разницы не почувствовало.

[ser970]

max_connections = максимально число соединений  - тут как бы не причем .

буфера увеличить  или делить длинный запрос на несколько мелких.
смотреть скольок памяти выделяется на процесс и так далее...

[NodenY45]

Вот что заметил, PF Nat работает порт в порт внешний к внутреннему айпи. -> 119.19.10.2:52610 (10.0.0.6:52610)

Код:

pfctl -sstate | grep 119.19.10.2
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 119.19.10.2:52610 (10.0.0.6:52610) -> 95.213.11.148:443       ESTABLISHED:ESTABLISHED
all tcp 119.19.10.2:52598 (10.0.0.6:52598) -> 87.240.131.113:443       ESTABLISHED:CLOSING
all tcp 119.19.10.2:52599 (10.0.0.6:52599) -> 87.240.131.113:443       ESTABLISHED:CLOSING
all tcp 119.19.10.2:52600 (10.0.0.6:52600) -> 87.240.131.113:443       ESTABLISHED:CLOSING
all tcp 119.19.10.2:52602 (10.0.0.6:52602) -> 87.240.165.73:443       ESTABLISHED:ESTABLISHED
all tcp 119.19.10.2:51781 (10.0.0.6:51781) -> 209.85.233.188:5228       ESTABLISHED:ESTABLISHED
all tcp 119.19.10.2:52605 (10.0.0.6:52605) -> 77.222.148.90:80       ESTABLISHED:ESTABLISHED
all udp 119.19.10.2:62009 (10.0.0.6:62009) -> 94.245.121.251:3544       MULTIPLE:MULTIPLE
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 37.53.86.247:54337       NO_TRAFFIC:SINGLE
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 81.30.165.63:1030       NO_TRAFFIC:SINGLE
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 91.207.105.26:60675       NO_TRAFFIC:SINGLE
all tcp 10.0.0.6:48504 (119.19.10.2:48504) <- 46.39.231.64:37703       CLOSED:SYN_SENT
all tcp 10.0.0.6:48504 (119.19.10.2:48504) <- 92.98.126.7:51004       CLOSED:SYN_SENT
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 92.98.126.7:58446       NO_TRAFFIC:SINGLE
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 178.125.101.4:48259       NO_TRAFFIC:SINGLE
all udp 10.0.0.6:48504 (119.19.10.2:48504) <- 88.135.120.216:46378       NO_TRAFFIC:SINGLE

А новый - железный NAT - присваивает порты рандомно. Может из за этого и время просчета увеличивается?

[NodenY45]

Сейчас снимает статистику раз в час   да и трафик то ~400мбит

[NodenY45]

Вот такая ситуация по top
Есть смысл сменить ipcad на другой коллектор?

[Efendy]

Да, ipcad медленный, потому что он не модуль ядра, а просто программа

[NodenY45]

Да, ipcad медленный, потому что он не модуль ядра, а просто программа

В какую сторону смотреть? я так понимаю надо ставить модуль netflow и выбрать что-то из ipacct или ng_netflow?

[Efendy]

netflow, да. Но по загрузке у тебя ipcad только на 3м месте. БОльшую часть ресурсов отжирает подсчет трафика и запись в базу.

[NodenY45]

netflow, да. Но по загрузке у тебя ipcad только на 3м месте. БОльшую часть ресурсов отжирает подсчет трафика и запись в базу.

проблема именно 87801 root          2  20    0   460M   404M select  6 696:38 100.00% /usr/bin/perl /usr/local/nodeny/nokernel.pl -m=collectors -d
так какая причина могла спровоцировать такой рост нагрузки на этот скрипт?
все таки указываете на увеличение таблицы юа икса?

[Efendy]

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

[NodenY45]

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

Я не прошу этого делать, просто логичное такому росту объяснение бы получить, ничего не меняли кроме ната, до его смены таких проблем не было.

[Warlock]

У меня такое было.. показывало в пики раз в 5-10 минут.. но тогда и нагрузка была около 3Г..