Перейти до

"Тупят" Инет-странички


Рекомендованные сообщения

Привет, люди. :rolleyes:

 

Проц - Celeron E1500 2,2ГГЦ, память 1,5ГГБ DDR2. Сетевые карты - "никакие" для этого, PCI и PCI-E типа DLINK, но на эту мамку лучше и не ткнёшь. В планах поменять железо, но пока...

FreeBSD 8.0-RELASE, СТГ, прозрачный Squid, pf для проброса и NATа + IPFW в качестве шейпа. Онлайн до 80 человек.

 

Проблема по вечерам бывает - тупят странички. Пингаю какой-нить хост, бывает что первый пакет не проходит, а потом пинг идёт нормально и без потерь. Т.е. подозреваю что проблема именно в DNS-запросах или в UDP.

 

У меня сервер просто перенаправляет DNS-запросы от юзеров в сети на DNS провайдера. Т.е. форвардит их.

Работает DNS по 53-му порту UDP, насколько я помню. При этом препядствие UDP составлять вроде некому - это широковещательный протокол, как камень в воду уронили - круги и пошли туда где вода до берега достаёт.

То что ему шейпер мешает - тоже быть не может, потому что себе например я не зажимаю траф. Да и качается/играется в этот момент замечательно - трабл только с Инет-страничками.

Заметил что такое случается когда народ активно играется - трафик к примеру мегабит 30-40, а UDP из него составляет 10Мбит.

На внешнем ИФ - всё чинно, никто 53-й порт не забивает, всё чётко - от меня к прову и обратно, соответственно внутреннему ИФ - от юзверей к серву. Траф UDP по порту 53 около 3 КБ/сек.

 

В такие моменты нагрузка СТГ - до 10%. Надо сказать, что конфигуратор в это время тоже здорово "тупит", если пытаться им приконнектиться (5555-й порт).

Внешний канал около 50Мбит, занято около 30, т.е. резерв есть.

 

Ниже даю вывод top -S, к сожалению пока не в момент бага, но может у Вас возникнут идеи.

 

last pid: 67520;  load averages:  0.95,  0.50,  0.43  up 6+03:40:28    17:00:52
95 processes:  4 running, 79 sleeping, 12 waiting

Mem: 75M Active, 1193M Inact, 173M Wired, 5928K Cache, 112M Buf, 47M Free
Swap: 4096M Total, 4096M Free


 PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root        2 171 ki31     0K    16K CPU0    0 195.8H 75.54% idle
  12 root       12 -60    -     0K    96K WAIT    0  55.1H 61.77% intr
61891 root       13  44  -19 22692K 16004K accept  0 328:45  2.20% stargazer
   0 root        8 -68    0     0K    56K -       0  22.6H  1.95% kernel
1322 nobody      1  44    0 16796K  9560K select  1  25:12  0.00% squid
  13 root        1  44    -     0K     8K -       1  23:38  0.00% yarrow
  18 root        1  44    -     0K     8K syncer  1  12:52  0.00% syncer
   7 root        1  44    -     0K     8K pftm    1   4:46  0.00% pfpurge
   3 root        1  -8    -     0K     8K -       1   1:59  0.00% g_up
 673 root        1  44    0  3348K  1156K select  1   1:33  0.00% routed
 816 root        1   1    0  3344K  1108K select  1   1:16  0.00% syslogd
   4 root        1  -8    -     0K     8K -       0   1:11  0.00% g_down
1003 root        1  44    0  7312K  2132K select  1   0:47  0.00% nmbd
95239 root        5  44    0 34972K 25372K kqread  1   0:37  0.00% named
1355 www         1  76    0 19800K  9868K accept  1   0:27  0.00% httpd
34769 www         1  76    0 19800K  9760K accept  1   0:26  0.00% httpd
   2 root        1  -8    -     0K     8K -       1   0:24  0.00% g_event
  19 root        1  44    -     0K     8K sdflus  0   0:21  0.00% softdepflush

Ссылка на сообщение
Поделиться на других сайтах

Это с клиентской машины, пару секунд думает.

> nslookup ya.ru
╤хЁтхЁ:  ya.ru
Addresses:  93.158.134.8
         213.180.204.8
         77.88.21.8

DNS request timed out.
   timeout was 2 seconds.
DNS request timed out.
   timeout was 2 seconds.
*** Превышено время ожидания запроса ya.ru

 

Это с сервера, тоже медленно:

#nslookup ya.ru

Server:		91.201.176.1
Address:	91.201.176.1#53

Non-authoritative answer:
Name:	ya.ru
Address: 93.158.134.8
Name:	ya.ru
Address: 213.180.204.8
Name:	ya.ru
Address: 77.88.21.8

Ссылка на сообщение
Поделиться на других сайтах

Это точно с сервером проблема? Может быть с клиентом только. Бывали аналогичные ситуации - непонятный глюк виндовса. Вбиваешь 1 ДНС - резолвится несколько секунд, вбиваешь другой - все моментально. Это было в единичных случаях. Как потом клиент рассказал - после переустановки винды оба ДНС работают быстро :rolleyes:

Попробуй для начала клиенту прописать какой то другой.

Еще вопрос: клиету выдается "локальный" ДНС? А уже на сервере форвардится? Или ему сразу ИП провайдера ?

Ссылка на сообщение
Поделиться на других сайтах

Ну, с сервера тоже тормозит.

У клиента статика. Прописывается ДНС=адрес роутера, и вторым - адрес шлюза.

Роутер форвардит запросы на внешние DNS прова, как и шлюз.

Но помятуя о первом, думаю клиенты тут ни при чём.

 

Это named.conf:

// $FreeBSD: src/etc/namedb/named.conf,v 1.21.2.1 2005/09/10 08:27:27 dougb Exp $
//
acl "local" { 10.0.0.0/24; 10.0.1.0/24; 10.0.2.0/24; 10.0.3.0/24; 10.0.4.0/24; 10.0.5.0/24; 10.0.6.0/24; 10.0.9.0/24; 127.0.0.1; };
       options {
directory	"/etc/namedb";
pid-file	"/etc/namedb/pid";
dump-file	"/etc/namedb/named_dump.db";
statistics-file	"/etc/namedb/named.stats";
forwarders { 127.0.0.1; xx.xx.xx.21; xx.xx.xx.22; };

allow-query { "local"; };
};	
zone "." {
    type hint;
    file "named.root";
};

zone "0.0.127.in-addr.arpa" {
    type master;
    file "/etc/namedb/master/localhost.rev";
    notify no; };

 

Это localhost.rev. Домена нет, так что не пугайтесь. :rolleyes: :

;	From: @(#)localhost.rev	5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;

$TTL	3600

@	IN	SOA	localhost.. root.localhost..  (
			20080820	; Serial
			3600	; Refresh
			900	; Retry
			3600000	; Expire
			3600 )	; Minimum
IN	NS	localhost..
1	IN	PTR	localhost..

Ссылка на сообщение
Поделиться на других сайтах

Народ!

Помогите, ну реально достало!

Пров отмахивается, говорит что это у меня трабл.

nslookup одинаково долго "думает" что с серверра, что с клиентской машины.

На клиентской машине пробовал ставить DNS прова в настройках протокола TCP/IP - та же лажа.

Подскажите хоть как правильно диагностировать, как найти причину?

Ссылка на сообщение
Поделиться на других сайтах

Попробуй прописать лайфовские днсы 212.58.160.33 и вторичный 212.58.160.34 или гугловские 8.8.8.8 и 8.8.4.4 и посмотреть будут задержки в ответах или нет. Если задержек нет, а на провайдерских есть, то будет весомый аргумент при обращении к прову. Если будут задержки, то хотя бы dns'ы прова исключишь...

Ссылка на сообщение
Поделиться на других сайтах

Ага... всем большое человеческое спасибо - Squid виноват.

Немного подправил конфиг - увеличил ему параметр cache_mem со 128М до 256М и перезапустил.

Уцепился я за этот DNS, хотя виновник явно себя выдавал. :)

Если ещё раз такое будет - хоть буду знать теперь куда копать.

Спасибо ещё раз! :)

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

Не тут-то было. :)

Опять началось.

Проц 2%, памяти почти 150М свободно... короче почти всё как на листниге вверху по top -S, но попа ещё та...

Трафик мегабит под 80 правда. Не знаю что думать. Серв один, нечего вместо него поставить. Грешу что мамка с сетевыми просто в затык уходит или FreeBSD 8 виновата.

 

Системы в этом не вижу никакой, кроме времени суток, когда куча народу чё-то качает и гамает в Инете.

Сейчас даже на сам серв зайти толком не могу. Причём пинги не теряются, только в самом начале бывает, потом всё чётко.. Обе сетевые гигабитные, одна PCIe, вторая PCI.

 

На винт почти ничего не пишется, может пару раз в минуту мигнёт и всё.

 

Что за процесс intr, ради повышения образованности спрашиваю?

 

Прошу не пинать, не спец я во Фре. :)

 

ifconfig:


re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:23:cd:b0:ec:46
inet ххх netmask 0xfffffffc broadcast ххх
inet ххх netmask 0xfffffffc broadcast ххх
inet ххх netmask 0xfffffffc broadcast ххх
inet ххх netmask 0xfffffffc broadcast ххх
inet ххх netmask 0xfffffffc broadcast ххх
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:21:91:d4:c8:4c
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
inet 10.0.0.9 netmask 0xffffff00 broadcast 10.0.0.255
inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
inet6 ::1 prefixlen 128 
inet 127.0.0.1 netmask 0xff000000 
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33200
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128

 

Нашёл одну банальную болячку. Отпишусь вечером как всё прошло.

Ссылка на сообщение
Поделиться на других сайтах

В общем обнаружил, что Squid висит в памяти как и положено, но ничерта не кеширует - каталог /var/squid/cache остаётся без изменений.

Т.е. что есть он, что нету. До этого проблем небыло, потому что народу было относительно мало.

 

У меня стоит связка ipfw + pf + прозрачный squid.

 

Вот только правило rdr в /etc/pf.conf вида:

rdr on $int_if proto tcp from $lan to any port 80 -> 127.0.0.1 port 3128

не срабатывает. Скорее всего потому что NAT "съедает" lan-адреса раньше него.

 

Пока мысль включить в ядре поддержку IPFIREWALL_FORWARD и сделать в ipfw - fwd 127.0.0.1,3128.

 

Так раньше и было, пока не задействовал pf.

 

Решение: http://local.com.ua/forum/topic/20228-pomogite-s-pf/page__view__findpost__p__159379

Ссылка на сообщение
Поделиться на других сайтах
  • 3 weeks later...

Так, история продолжается. Squid исключается - я его вырубил.

 

 

top -SIP:

last pid:  7297;  load averages:  0.22,  0.24,  0.19  up 14+18:21:16    19:29:59
93 processes:  5 running, 77 sleeping, 11 waiting
CPU 0: 3.0% user, 0.0% nice, 16% system, 37.8 interrupt, 42.3% idle
CPU 1: 1.5% user, 0.0% nice, 19.5% system, 54.5 interrupt, 24.4% idle
Mem: 106M Active, 913M Inact, 199M Wired, 3420K Cache, 112M Buf, 272M Free
Swap: 4096M Total, 52K Used, 4096M Free



 PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  12 root       12 -28    -     0K    96K CPU1    1 131.6H 80.57% intr
  11 root        2 171 ki31     0K    16K RUN     0 488.4H 67.33% idle
   0 root        8 -68    0     0K    56K -       0  58.1H  5.66% kernel
2394 root       13  44  -19 23716K 16496K select  0  20.9H  2.98% stargazer

 

Такая картина при трафике - всплеск в 35Мбит, вместо привычных 15-20. Большая нагрузка на серв? Дешёвые сетевые виноваты? Даже на внутреннюю страничку с трудом захожу.

Ткните пальцем, не вижу причины. :)

 

И скажите пожалуйста - что за демон intr, кто-нибудь! :mellow:

 

Пытаюсь сейчас с cервера пингануть local.com.ua - пинг идёт на 3-4-ую попытку. Пишет "cannot resolve local.com.ua: Host name lookup failure" или выдаёт вместо ответов "sendto: Operation not permitted". Потом пинг идёт нормально.

dig @127.0.0.1 local.com.ua выдаёт без запинки:

 

; <<>> DiG 9.6.1-P1 <<>> @127.0.0.1 local.com.ua
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 488
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;local.com.ua.			IN	A

;; ANSWER SECTION:
local.com.ua.		8936	IN	A	194.0.88.26

;; AUTHORITY SECTION:
local.com.ua.		8936	IN	NS	ns.local.com.ua.
local.com.ua.		8936	IN	NS	ns.irc.ks.ua.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 12 20:16:46 2010
;; MSG SIZE  rcvd: 87

 

ППЦ какой-то. :)

 

 

 

Нашёл похожую проблему, наконец-то. Именно благодаря вылезшему "sendto: Operation not permitted" - по Яндексу.

 

Добавил в /etc/pf.conf:

set limit { states 200000, frags 100000, src-nodes 50000}
...
pass all no state

Отпишусь как оно.

 

Да, причина именно в этом была.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...