- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Подскажите что за дела, подозрение что где-то мы переборщили с тюнингом tcp.
Дебиан 6, всё по умолчанию, кроме:
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
echo 20 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 6000 > /proc/sys/vm/dirty_writeback_centisecs
echo 1024 > /proc/sys/net/core/somaxconn
echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 500000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes
Подобное было пару раз уже, скорее вместе с дос атакой, cервер внезапно лёг, пропал пинг, и даже в лог до конца не записалась строка, всё что есть подозрительное из syslog
Jan 24 21:16:01 s15 kernel: [676080.477708] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:01 s15 kernel: [676080.517754] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:01 s15 kernel: [676080.550447] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:02 s15 kernel: [676080.993506] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:02 s15 kernel: [676081.102523] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:02 s15 kernel: [676081.765382] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:03 s15 kernel: [676082.763077] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:03 s15 kernel: [676082.811350] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:04 s15 kernel: [676082.890740] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:06 s15 /USR/SBIN/CRON[7982]: (CRON) error (grandchild #8080 failed with exit status 4)
Jan 24 21:16:06 s15 kernel: [676085.760410] __ratelimit: 7 callbacks suppressed
Jan 24 21:16:06 s15 kernel: [676085.760439] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:06 s15 kernel: [676085.801933] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:06 s15 kernel: [676085.865134] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 kernel: [676085.924558] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 kernel: [676086.264375] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 kernel: [676086.448502] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 kernel: [676086.520202] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 /USR/SBIN/CRON[7985]: (CRON) error (grandchild #8078 failed with exit status 8)
Jan 24 21:16:07 s15 kernel: [676086.596231] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:07 s15 kernel: [676086.665703] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:08 s15 kernel: [676087.085362] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.245832] __ratelimit: 25 callbacks suppressed
Jan 24 21:16:12 s15 kernel: [676091.245861] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.715214] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.758958] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.783669] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.819011] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:12 s15 kernel: [676091.859013] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:13 s15 kernel: [676091.925048] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:13 s15 kernel: [676092.374882] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:13 s15 kernel: [676092.407041] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:13 s15 kernel: [676092.467405] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:17 s15 kernel: [676096.765954] __ratelimit: 36 callbacks suppressed
Jan 24 21:16:17 s15 kernel: [676096.765984] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:18 s15 kernel: [676096.961980] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:18 s15 kernel: [676097.005748] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:18 s15 kernel: [676097.709605] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:19 s15 kernel: [676097.882042] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:19 s15 kernel: [676097.933587] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:20 s15 kernel: [676099.282043] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:20 s15 kernel: [676099.739838] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:20 s15 kernel: [676099.797561] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:20 s15 kernel: [676099.850203] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.436503] __ratelimit: 6 callbacks suppressed
Jan 24 21:16:23 s15 kernel: [676102.436530] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.492524] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.533376] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.569862] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.624494] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.656482] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.684553] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.712439] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.740454] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:23 s15 kernel: [676102.773755] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:28 s15 kernel: [676107.567471] __ratelimit: 34 callbacks suppressed
Jan 24 21:16:28 s15 kernel: [676107.567500] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:28 s15 kernel: [676107.619287] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:28 s15 kernel: [676107.667322] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:28 s15 kernel: [676107.756396] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676107.863362] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676107.967251] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676108.043182] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676108.092504] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676108.143211] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:29 s15 kernel: [676108.183160] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:34 s15 kernel: [676113.150954] __ratelimit: 30 callbacks suppressed
Jan 24 21:16:34 s15 kernel: [676113.150981] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:34 s15 kernel: [676113.730030] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:34 s15 kernel: [676113.778037] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:35 s15 kernel: [676114.114131] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:35 s15 kernel: [676114.393742] r8169 0000:06:00.0: eth0: link up
Jan 24 21:16:35 s15 kernel: [676114.446411]
В messages была ещё строка в самом верху
Последнее время досы участились с большими ботнетами (
r8169
может для начала попробовать 8168?
непосредственно ошибки к "тюнингу" отношения не имеют - это дрова железки
Ого, дрова не от той сетевой стоят, как же так вышло, и как это вообще можно исправить...
Дебиан просто обновлялся через apt-get upgrade/update, проблема уже где-то с месяц как себя проявляет, 2 раза падал сервак.
Вот информация по сетевой:
Subsystem: Micro-Star International Co., Ltd. Device 7522
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 256 bytes
Interrupt: pin A routed to IRQ 29
Region 0: I/O ports at e800
Region 2: Memory at fbeff000 (64-bit, non-prefetchable)
Region 4: Memory at faff0000 (64-bit, prefetchable)
[virtual] Expansion ROM at faf00000 [disabled]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00000 Data: 4089
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 05, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 01-00-00-00-68-4c-e0-00
Kernel driver in use: r8169
Для centos есть готовый rpm пакет, который ставит нужный драйвер
Не сомневаюсь, что для debian тоже есть аналогичный пакет
Dimanych, еще раз, нужно попробовать 8168
http://r8168.googlecode.com/files/r8168-8.027.00.tar.bz2
Хотел написать страшно, но потом нашёл тему от хецнеров, и сервер этот так же у них.
http://wiki.hetzner.de/index.php/Installation_des_r8168-Treibers/ru
Dimanych, ну и? помогло?
Dimanych, ну и? помогло?
А как я определю, было 2 падения за месяц, нужно смотреть на протяжении времени.
В нормальных условиях помоему проблем нет, только при дос атаках.
Dimanych, ну можно просто трафик погенерить, от этого падает
Вот ещё нашёл для дебиана, намного проще будет такой зарядить, но надёжней ли)
http://packages.debian.org/de/sid/r8168-dkms