LINUX.ORG.RU

помирает pppd сессия при существенной нагрузке на систему в целом

 


0

1

Привет
Столкнулся с такой проблемой. Не знаю, было ли раньше, или только сейчас проявилось.
В интернеты хожу по pppoe, соответственно pppd. Раньше провайдер нарезал сессии каждые 24 часа, с мая(может раньше) что-то поменяли, и теперь сессия живет бессрочно. По крайней мере так говорят логи ppp.
И вот стал замечать проблему. Например 2 cpuburn и 2 dd грузят систему, и через какое-то время(приблизительно) сначала отваливается pppoe сессия, ну и тут же поднимает.
Так вот вопрос. Может ли cpu/io нагрузка быть причиной этому?
И если да, то как бороться? типа ionice -c 1 -n 0 nice -n '-10' pppd ... ?

// debian unstable, x86_64, amd e350
Спасибо :)

а включить отладку и посмотреть причину обрыва в логах и dmesg ?

Может проблема с железом проявляется в виде глюков при перегреве?

vel ★★★★★
()
Ответ на: комментарий от vel

да в логах все норм

May  5 19:34:26 gw pppd[61110]: Script /etc/ppp/ip-up finished (pid 7640), status = 0x0
May  5 22:37:10 gw pppd[61110]: No response to 3 echo-requests
May  5 22:37:10 gw pppd[61110]: Serial link appears to be disconnected.
May  5 22:37:10 gw pppd[61110]: Connect time 182.8 minutes.
May  5 22:37:10 gw pppd[61110]: Sent 3576240591 bytes, received 2312470577 bytes.
May  5 22:37:10 gw pppd[61110]: Script /etc/ppp/ip-down started (pid 22620)
May  5 22:37:10 gw pppd[61110]: sent [LCP TermReq id=0x8 "Peer not responding"]
May  5 22:37:11 gw pppd[61110]: Script /etc/ppp/ip-down finished (pid 22620), status = 0x1
May  5 22:37:13 gw pppd[61110]: sent [LCP TermReq id=0x9 "Peer not responding"]
May  5 22:37:16 gw pppd[61110]: Connection terminated.
May  5 22:37:16 gw pppd[61110]: Modem hangup
как будто cpu захлебывается и забивает на pppd процесс
похожие проблемы гуглятся, но только в контексте модемов/роутеров

ii343hbka ★★★
() автор топика

Ога, попробовать поднять приоритет pppd и поставить класс Idle в ionice для dd

whoami
()
Ответ на: комментарий от ii343hbka

amd e350 - не быстрая машинка. Активный ввод-вывод на ней может кушать много cpu, но не до такой же степени!

У меня на старом ноуте число потерь/ошибок на встроенной сетевушке было пропорционально температуре :(

добавить время и число lcp-шных пакетов не пробовал (или совсем отключить) ?

Помониторить число ошибок на сетевом интерфейсе... Может кто-то помирает между тобой и провайдерским pppoe роутером...

Запустить пинг до шлуюза по-умолчанию и посмотреть...

А iptables используется для фильтрации ?

А нет ли какой софтинки типа NM ?

vel ★★★★★
()
Ответ на: комментарий от vel
eth0      Link encap:Ethernet  HWaddr f4:6d:04:d8:9f:00
          UP BROADCAST RUNNING MULTICAST  MTU:9194  Metric:1
          RX packets:1369410379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1546396242 errors:0 dropped:4419 overruns:0 carrier:0
          collisions:0 txqueuelen:16384
          RX bytes:907165730574 (844.8 GiB)  TX bytes:1253451102743 (1.1 TiB)
          Interrupt:43 Base address:0xa000

вроде не так много и то dropped
число lcp пакетов специально низкое - просто влом городить скрипт, который будет мониторить интернеты, поэтому в /etc/ppp/peers/provider есть persist и 1секундный таймаут на lcp пакеты. Чтобы, значит, интернеты быстрее встали, если лягут
шлюз пинговать не пробовал
iptables есть
nm не использую

я вот тоже начинаю думать, что это в провайдере, может косяк
потому что сессия с таким же выхлопом рвется и когда я вообще не трогаю тачку

короче буду посмотреть, спасибо :)

ii343hbka ★★★
() автор топика
Последнее исправление: ii343hbka (всего исправлений: 1)
Ответ на: комментарий от ii343hbka

Если оно смотрит в сторону провайдера и в договоре этот пункт явно не описан, то есть смысл вернуть на стандартный для езернета 1500. ХЗ как будет реагировать провайдерское оборудование на пакеты большой длины.

vel ★★★★★
()

[решено]

похоже так сложились звезды

пересобрал ppp со всякими march=native mtune=native и когда раньше сессия рвалась теперь норм. И это без игры приоритетами

а вот, кстати, io планировщики и приоритеты влияют на сеть, или только на блочные устройства?

может, конечно, мне так позвело

ii343hbka ★★★
() автор топика
Ответ на: [решено] от ii343hbka

Влияние разве что косвенное, но не менее реальное: если блочное устройство медленное, скорость ответа от него нестабильна и наблюдается сильный cache pressure, то тогда вся система может начать лагать в некоторых ситуациях (см. известно-эпичный kernel bug 12309)

whoami
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.