dee Posted October 19, 2012 (edited) было 2 машины одна пролиант не свеженький и новый "гражданский" сервак с двумя сетёвками 82572EI , обе при определённой нагрузке mpd рандомно ребутались раз в 4 - 6 дней , взял "гражданский" комп , всё снёс , поставил чистую девятку : "9.0-RELEASE FreeBSD" , поставил из портов мпд5 , сконфигурил pptp + l2tp , по мелочи доставил совта (модули перла , и мускула) , собрал ядро с х64 + нетграф + ipferewall) , подключил в радиус серверу . всё бы хорошо , но всё так же ребутается в логах вообще нет ничего подозрительного , стоит на всяк случай вачдог (ребутнуться может как при сильно загрузке 500 тунелей , так и ночью когда работают только роутеры без траффа = 100 - 200 тонелей) оптимизация минимальная : autoboot_delay="3"net.graph.recvspace="524288" kern.maxusers="2048" kern.ipc.nmbclusters="32768" hw.igb.rxd="4096" hw.igb.txd="4096" # ichwd_load="YES" /sbin/sysctl net.graph.recvspace=524288 /sbin/sysctl net.graph.maxalloc=4096 /sbin/sysctl net.graph.maxdgram=524288 /sbin/sysctl kern.ipc.maxsockbuf=2621440 в мпд юзаются ngcar для нарезки скорости. что сделать , что бы хотя бы приблизительно понять из-за чего оно ребутится ? ядро собрано с опцией makeoptions DEBUG=-g пс. без включеной мпд всё работает без ребутов. Edited October 19, 2012 by dee Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted October 19, 2012 пф или ипфв в кач фаера, в остальном поиск по форуму. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ichthyandr Posted October 19, 2012 как вариант - посмотреть vmcore, если он есть, правда нужно собрать ядро с отладкой Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Hawk128 Posted October 19, 2012 Тут без вариантов, уберите из ядра INET6 и рядом зависимую опцию. Пересобирите и радуйтесь. Сам наступил на эти грабли когда пытался внедрить IPv6. Ошибка есть, не совсем четкая. В Нетграфе при большой нагрузке при наличии включенного (даже неиспользующегося) IPv6. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dee Posted October 20, 2012 спасибо за советы , ядро пересобрал , теперь посмотрю на то как будет работать (отпишусь о результатах). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Hawk128 Posted October 21, 2012 Ок. Ждемс. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dee Posted October 29, 2012 (edited) всё тоже самое ребут произошел в самое не нагрузное время , висело примерно 220 тунелей из максимальных 450 . Последнее сообщение в мессаджах датируется более чем за 12 часов до ребута. Ещё на вскидку , на машине работает бгп+оспф + обрабатываются пара скриптов по заполнения фаервола (каждые 10 минут, заполняет одну табличку вне зависимости есть там такая запись или нет). С написания моего последнего сообщения он уже 2 раза ребутнулся (сперва на старом ядре с V6 и загразившись в новое сегодня опять ребутнулся). Edited October 29, 2012 by dee Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
andriko Posted October 29, 2012 так консоль у Вас есть или нет, чего-то оно там на консоль должно ругнуться в момент ребута. после ипв6 я бы грешил на оспф, 9.0-RELEASE + малтикаст и + мпд с динамическими интерфейсами ..... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Hawk128 Posted October 29, 2012 Странно. У меня на 100% в этом была проблема. Включаю - ребут в течении недели гарантирован, отключаю - год как влитой... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
photon Posted October 29, 2012 (edited) Я для себя установил такое правило: в production ставить новую версию только после того, как выйдет x.1-RELEASE. Наблюдается ли на этой машине постоянный рост используемой памяти после нескольких часов работы? Edited October 29, 2012 by photon Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vadimv2 Posted October 31, 2012 Была похожая ситуация, решилось покупкой Cisco 7204 с NPE G2... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dee Posted November 6, 2012 очередной раз убедился в несовершенстве бсд.... + глюки с проксиарп Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
apm Posted November 7, 2012 А есть примеры совершенства? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kosd Posted November 13, 2012 (edited) FreeBSD 8.3 + mpd5 у меня недели 3 работало нормально, а потом паники сериями по 3-5 перезагрузок было. Поставил FreeBSD 9.0. [root@krynka ~]# uname -a FreeBSD krynka 9.0-RELEASE-p4 FreeBSD 9.0-RELEASE-p4 #0: Mon Nov 12 11:15:22 EET 2012 root@krynka:/usr/src/sys/amd64/compile/ABILLS_12_11_2012 amd64 Прошло 3, 4 недели и снова паники. Oct 30 09:29:15 krynka kernel: Fatal trap 12: page fault while in kernel mode Oct 30 09:29:15 krynka kernel: cpuid = 2; apic id = 04 Oct 30 09:29:15 krynka kernel: fault virtual address = 0x18 Oct 30 09:29:15 krynka kernel: fault code = supervisor read data, page not present Oct 30 09:29:15 krynka kernel: instruction pointer = 0x20:0xffffffff808b2017 Oct 30 09:29:15 krynka kernel: stack pointer = 0x28:0xffffff8000263d80 Oct 30 09:29:15 krynka kernel: frame pointer = 0x28:0xffffff8000263de0 Oct 30 10:07:49 krynka syslogd: kernel boot file is /boot/kernel/kernel Oct 30 10:07:49 krynka kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Oct 30 10:07:49 krynka kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Oct 30 10:07:49 krynka kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 30 10:07:49 krynka kernel: current process = 13 (ng_queue0) Oct 30 10:07:49 krynka kernel: trap number = 12 Oct 30 10:07:49 krynka kernel: panic: page fault Oct 30 10:07:49 krynka kernel: cpuid = 2 Oct 30 10:07:49 krynka kernel: KDB: stack backtrace: Oct 30 10:07:49 krynka kernel: #0 0xffffffff8088725e at kdb_backtrace+0x5e Oct 30 10:07:49 krynka kernel: #1 0xffffffff80851e17 at panic+0x187 Oct 30 10:07:49 krynka kernel: #2 0xffffffff80ab7b40 at trap_fatal+0x290 Oct 30 10:07:49 krynka kernel: #3 0xffffffff80ab7e89 at trap_pfault+0x1f9 Oct 30 10:07:49 krynka kernel: #4 0xffffffff80ab834f at trap+0x3df Oct 30 10:07:49 krynka kernel: #5 0xffffffff80aa27ef at calltrap+0x8 Oct 30 10:07:49 krynka kernel: #6 0xffffffff8097f5c3 at ip_fragment+0x1c3 Oct 30 10:07:49 krynka kernel: #7 0xffffffff809805cd at ip_output+0xdbd Oct 30 10:07:49 krynka kernel: #8 0xffffffff8097c3e3 at ip_forward+0x303 Oct 30 10:07:49 krynka kernel: #9 0xffffffff8097da7b at ip_input+0x5ab Oct 30 10:07:49 krynka kernel: #10 0xffffffff8090f99b at netisr_dispatch_src+0x20b Oct 30 10:07:49 krynka kernel: #11 0xffffffff8141dda4 at ng_iface_rcvdata+0x114 Oct 30 10:07:49 krynka kernel: #12 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:07:49 krynka kernel: #13 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:07:49 krynka kernel: #14 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:07:49 krynka kernel: #15 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:07:49 krynka kernel: #16 0xffffffff814273fc at ng_car_rcvdata+0xbc Oct 30 10:07:49 krynka kernel: #17 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:07:49 krynka kernel: Uptime: 3d13h46m48s Oct 30 10:07:49 krynka kernel: Dumping 678 out of 4051 MB:..3%..12%..22%..31%..41%..52%..62%..71%..81%..92%Attempt to write outside dump device boundaries. Oct 30 10:07:49 krynka kernel: offset(499289907712), mediaoffset(494994998272), length(65536), mediasize(4294967296). Oct 30 10:18:04 krynka kernel: Fatal trap 12: page fault while in kernel mode Oct 30 10:18:04 krynka kernel: cpuid = 1; apic id = 02 Oct 30 10:18:04 krynka kernel: fault virtual address = 0x18 Oct 30 10:18:55 krynka syslogd: kernel boot file is /boot/kernel/kernel Oct 30 10:18:55 krynka kernel: fault code = supervisor read data, page not present Oct 30 10:18:55 krynka kernel: instruction pointer = 0x20:0xffffffff808b2017 Oct 30 10:18:55 krynka kernel: stack pointer = 0x28:0xffffff8000263d80 Oct 30 10:18:55 krynka kernel: frame pointer = 0x28:0xffffff8000263de0 Oct 30 10:18:55 krynka kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Oct 30 10:18:55 krynka kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Oct 30 10:18:55 krynka kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 30 10:18:55 krynka kernel: current process = 13 (ng_queue0) Oct 30 10:18:55 krynka kernel: trap number = 12 Oct 30 10:18:55 krynka kernel: panic: page fault Oct 30 10:18:55 krynka kernel: cpuid = 1 Oct 30 10:18:55 krynka kernel: KDB: stack backtrace: Oct 30 10:18:55 krynka kernel: #0 0xffffffff8088725e at kdb_backtrace+0x5e Oct 30 10:18:55 krynka kernel: #1 0xffffffff80851e17 at panic+0x187 Oct 30 10:18:55 krynka kernel: #2 0xffffffff80ab7b40 at trap_fatal+0x290 Oct 30 10:18:55 krynka kernel: #3 0xffffffff80ab7e89 at trap_pfault+0x1f9 Oct 30 10:18:55 krynka kernel: #4 0xffffffff80ab834f at trap+0x3df Oct 30 10:18:55 krynka kernel: #5 0xffffffff80aa27ef at calltrap+0x8 Oct 30 10:18:55 krynka kernel: #6 0xffffffff8097f5c3 at ip_fragment+0x1c3 Oct 30 10:18:55 krynka kernel: #7 0xffffffff809805cd at ip_output+0xdbd Oct 30 10:18:55 krynka kernel: #8 0xffffffff8097c3e3 at ip_forward+0x303 Oct 30 10:18:55 krynka kernel: #9 0xffffffff8097da7b at ip_input+0x5ab Oct 30 10:18:55 krynka kernel: #10 0xffffffff8090f99b at netisr_dispatch_src+0x20b Oct 30 10:18:55 krynka kernel: #11 0xffffffff8141dda4 at ng_iface_rcvdata+0x114 Oct 30 10:18:55 krynka kernel: #12 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:18:55 krynka kernel: #13 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:18:55 krynka kernel: #14 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:18:55 krynka kernel: #15 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:18:55 krynka kernel: #16 0xffffffff814273fc at ng_car_rcvdata+0xbc Oct 30 10:18:55 krynka kernel: #17 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:18:55 krynka kernel: Uptime: 10m25s Oct 30 10:18:55 krynka kernel: panic: bufwrite: buffer is not busy??? Oct 30 10:18:55 krynka kernel: cpuid = 1 Oct 30 10:18:55 krynka kernel: Dumping 364 out of 4051 MB:Copyright (c) 1992-2012 The FreeBSD Project. Oct 30 10:28:16 krynka kernel: Fatal trap 12: page fault while in kernel mode Oct 30 10:28:16 krynka kernel: cpuid = 1; apic id = 02 Oct 30 10:28:16 krynka kernel: fault virtual address = 0x18 Oct 30 10:28:16 krynka kernel: fault code = supervisor read data, page not present Oct 30 10:28:16 krynka kernel: instruction pointer = 0x20:0xffffffff808b2017 Oct 30 10:28:16 krynka kernel: stack pointer = 0x28:0xffffff800026dd80 Oct 30 10:28:16 krynka kernel: frame pointer = 0x28:0xffffff800026dde0 Oct 30 10:29:07 krynka syslogd: kernel boot file is /boot/kernel/kernel Oct 30 10:29:07 krynka kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Oct 30 10:29:07 krynka kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Oct 30 10:29:07 krynka kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 30 10:29:07 krynka kernel: current process = 13 (ng_queue2) Oct 30 10:29:07 krynka kernel: trap number = 12 Oct 30 10:29:07 krynka kernel: panic: page fault Oct 30 10:29:07 krynka kernel: cpuid = 1 Oct 30 10:29:07 krynka kernel: KDB: stack backtrace: Oct 30 10:29:07 krynka kernel: #0 0xffffffff8088725e at kdb_backtrace+0x5e Oct 30 10:29:07 krynka kernel: #1 0xffffffff80851e17 at panic+0x187 Oct 30 10:29:07 krynka kernel: #2 0xffffffff80ab7b40 at trap_fatal+0x290 Oct 30 10:29:07 krynka kernel: #3 0xffffffff80ab7e89 at trap_pfault+0x1f9 Oct 30 10:29:07 krynka kernel: #4 0xffffffff80ab834f at trap+0x3df Oct 30 10:29:07 krynka kernel: #5 0xffffffff80aa27ef at calltrap+0x8 Oct 30 10:29:07 krynka kernel: #6 0xffffffff8097f5c3 at ip_fragment+0x1c3 Oct 30 10:29:07 krynka kernel: #7 0xffffffff809805cd at ip_output+0xdbd Oct 30 10:29:07 krynka kernel: #8 0xffffffff8097c3e3 at ip_forward+0x303 Oct 30 10:29:07 krynka kernel: #9 0xffffffff8097da7b at ip_input+0x5ab Oct 30 10:29:07 krynka kernel: #10 0xffffffff8090f99b at netisr_dispatch_src+0x20b Oct 30 10:29:07 krynka kernel: #11 0xffffffff8141dda4 at ng_iface_rcvdata+0x114 Oct 30 10:29:07 krynka kernel: #12 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:29:07 krynka kernel: #13 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:29:07 krynka kernel: #14 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:29:07 krynka kernel: #15 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 10:29:07 krynka kernel: #16 0xffffffff814273fc at ng_car_rcvdata+0xbc Oct 30 10:29:07 krynka kernel: #17 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 10:29:07 krynka kernel: Uptime: 9m33s Oct 30 10:29:07 krynka kernel: Dumping 707 out of 4051 MB:Copyright (c) 1992-2012 The FreeBSD Project. Oct 30 12:42:46 krynka kernel: Limiting icmp ping response from 360 to 200 packets/sec Oct 30 12:52:54 krynka kernel: Oct 30 13:25:14 krynka syslogd: kernel boot file is /boot/kernel/kernel Oct 30 13:25:14 krynka kernel: Fatal trap 12: page fault while in kernel mode Oct 30 13:25:14 krynka kernel: cpuid = 3; apic id = 06 Oct 30 13:25:14 krynka kernel: fault virtual address = 0x18 Oct 30 13:25:14 krynka kernel: fault code = supervisor read data, page not present Oct 30 13:25:14 krynka kernel: instruction pointer = 0x20:0xffffffff808b2017 Oct 30 13:25:14 krynka kernel: stack pointer = 0x28:0xffffff800026dd80 Oct 30 13:25:14 krynka kernel: frame pointer = 0x28:0xffffff800026dde0 Oct 30 13:25:14 krynka kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Oct 30 13:25:14 krynka kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Oct 30 13:25:14 krynka kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 30 13:25:14 krynka kernel: current process = 13 (ng_queue2) Oct 30 13:25:14 krynka kernel: trap number = 12 Oct 30 13:25:14 krynka kernel: panic: page fault Oct 30 13:25:14 krynka kernel: cpuid = 3 Oct 30 13:25:14 krynka kernel: KDB: stack backtrace: Oct 30 13:25:14 krynka kernel: #0 0xffffffff8088725e at kdb_backtrace+0x5e Oct 30 13:25:14 krynka kernel: #1 0xffffffff80851e17 at panic+0x187 Oct 30 13:25:14 krynka kernel: #2 0xffffffff80ab7b40 at trap_fatal+0x290 Oct 30 13:25:14 krynka kernel: #3 0xffffffff80ab7e89 at trap_pfault+0x1f9 Oct 30 13:25:14 krynka kernel: #4 0xffffffff80ab834f at trap+0x3df Oct 30 13:25:14 krynka kernel: #5 0xffffffff80aa27ef at calltrap+0x8 Oct 30 13:25:14 krynka kernel: #6 0xffffffff8097f5c3 at ip_fragment+0x1c3 Oct 30 13:25:14 krynka kernel: #7 0xffffffff809805cd at ip_output+0xdbd Oct 30 13:25:14 krynka kernel: #8 0xffffffff8097c3e3 at ip_forward+0x303 Oct 30 13:25:14 krynka kernel: #9 0xffffffff8097da7b at ip_input+0x5ab Oct 30 13:25:14 krynka kernel: #10 0xffffffff8090f99b at netisr_dispatch_src+0x20b Oct 30 13:25:14 krynka kernel: #11 0xffffffff8141dda4 at ng_iface_rcvdata+0x114 Oct 30 13:25:14 krynka kernel: #12 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 13:25:14 krynka kernel: #13 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 13:25:14 krynka kernel: #14 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 13:25:14 krynka kernel: #15 0xffffffff809528ae at ng_snd_item+0x39e Oct 30 13:25:14 krynka kernel: #16 0xffffffff814273fc at ng_car_rcvdata+0xbc Oct 30 13:25:14 krynka kernel: #17 0xffffffff809538fb at ng_apply_item+0x22b Oct 30 13:25:14 krynka kernel: Copyright (c) 1992-2012 The FreeBSD Project. Пробовал и ng_car шейпер, и dummynet+ipfw. Тюнинг убирал полностью, ipv6 отключал. Убрал из ядра netgraph - 8 дней аптайма и завис, но без паники, скорее всего из-за перетекания памяти из free в inact. Кстати, с ng_car шейпером у меня в 2 раза меньше lavr по сравнению с dummynet+ipfw. Сейчас убрал из ядра все, остался родной generic: # For ABILLS #options IPFIREWALL #options IPFIREWALL_DEFAULT_TO_ACCEPT #options DUMMYNET #options NETGRAPH #options NETGRAPH_ETHER #options NETGRAPH_PPPOE #options IPFILTER #options IPFILTER_LOG #options IPDIVERT #device coretemp #options IPFIREWALL_FORWARD #options IPFIREWALL_NAT #options LIBALIAS Пусть все грузится модулями. Посморим будут ли еще паники. Вот конфиг mpd: startup: set global enable tcp-wrapper set console self 127.0.0.1 5005 set user admin ****** admin set console open default: load pptp_server pptp_server: create bundle template B_pptp set iface idle 0 set iface enable tcpmssfix set ipcp no vjcomp # set iface up-script "/usr/abills/libexec/linkupdown mpd up" # set iface down-script "/usr/abills/libexec/linkupdown mpd down" set ipcp dns X.X.X.X create link template L_pptp pptp set link action bundle B_pptp set link enable peer-as-calling set pptp disable windowing set pptp self 172.17.229.254 load server_common server_common: set link no pap eap set link yes chap-md5 set link keep-alive 20 60 set iface mtu 1452 set link mtu 1452 set link enable incoming set link no acfcomp protocomp load radius radius: set radius config /etc/radius.conf set radius retries 3 set radius timeout 10 set auth acct-update 60 set auth enable radius-auth set auth enable radius-acct set auth disable internal Вот sysctl.conf: net.graph.maxdgram=256000 #kern.ipc.maxsockbuf=8388608 net.graph.recvspace=256000 # TCP bufer size net.inet.tcp.recvspace=65535 # incoming TCP queue size kern.ipc.somaxconn=4096 # incoming packets queue size #net.inet.ip.intr_queue_maxlen=2000 Вот /boot/loader.conf: #kern.maxdsiz="2G" #kern.dfldsiz="2G" #Freebsd 7.2 #kern.ipc.nmbclusters=262144 #kern.ipc.maxsockets=262144 net.graph.maxalloc=3072 kern.maxusers=1024 # maximize if ngctl not enough space) (amd64) kern.ipc.maxpipekva=536870912 # maximize if ngctl not enough space) (i386) #kern.ipc.maxpipekva=256000009 #kern.maxfiles=204800 #kern.maxfilesperproc=200000 #kern.ipc.maxsockbuf=524288 #net.inet6.ip6.auto_linklocal=0 hw.em.txd=4096 hw.em.rxd=4096 top -SHPI: last pid: 40065; load averages: 0.41, 0.44, 0.41 up 0+12:06:32 12:07:02 135 processes: 5 running, 109 sleeping, 21 waiting CPU 0: 0.0% user, 0.0% nice, 0.8% system, 15.7% interrupt, 83.5% idle CPU 1: 0.8% user, 0.0% nice, 4.3% system, 0.8% interrupt, 94.1% idle CPU 2: 2.0% user, 0.0% nice, 3.9% system, 1.2% interrupt, 92.9% idle CPU 3: 0.4% user, 0.0% nice, 5.9% system, 0.0% interrupt, 93.7% idle Mem: 163M Active, 501M Inact, 513M Wired, 752K Cache, 415M Buf, 2738M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K CPU3 3 708:36 100.00% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 1 702:13 95.17% idle{idle: cpu1} 11 root 155 ki31 0K 64K RUN 2 704:28 93.55% idle{idle: cpu2} 11 root 155 ki31 0K 64K RUN 0 668:57 83.59% idle{idle: cpu0} 12 root -92 - 0K 336K WAIT 2 35:38 11.57% intr{irq256: em0:rx 0} 12 root -92 - 0K 336K WAIT 0 12:08 4.69% intr{irq259: em1:rx 0} 861 root -16 - 0K 64K sleep 0 11:54 4.49% ng_queue{ng_queue1} 861 root -16 - 0K 64K sleep 3 12:00 4.39% ng_queue{ng_queue0} 861 root -16 - 0K 64K sleep 0 12:00 4.05% ng_queue{ng_queue2} 861 root -16 - 0K 64K sleep 2 11:55 3.96% ng_queue{ng_queue3} 12 root -92 - 0K 336K WAIT 0 3:29 0.49% intr{irq260: em1:tx 0} 12 root -92 - 0K 336K WAIT 0 3:26 0.49% intr{irq257: em0:tx 0} netstat -hdw1: [root@krynka ~]# netstat -hdw1 input (Total) output packets errs idrops bytes packets errs bytes colls drops 67k 0 0 42M 70k 0 50M 0 0 67k 0 0 42M 70k 0 51M 0 0 67k 0 0 42M 72k 0 52M 0 0 69k 0 0 42M 72k 0 53M 0 0 65k 0 0 40M 67k 0 50M 0 0 65k 0 0 39M 66k 0 47M 0 0 vmstat -i: [root@krynka ~]# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq16: ehci0 65684 1 irq23: ehci1 66081 1 cpu0:timer 48870277 1118 irq256: em0:rx 0 222785124 5097 irq257: em0:tx 0 232473983 5319 irq258: em0:link 21 0 irq259: em1:rx 0 159079769 3639 irq260: em1:tx 0 153241788 3506 irq261: em1:link 2 0 irq262: ahci0 154747 3 cpu3:timer 33433174 764 cpu1:timer 36846475 843 cpu2:timer 38241059 874 Total 925258190 21170 vmstat -z: [root@krynka ~]# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq16: ehci0 65684 1 irq23: ehci1 66081 1 cpu0:timer 48870277 1118 irq256: em0:rx 0 222785124 5097 irq257: em0:tx 0 232473983 5319 irq258: em0:link 21 0 irq259: em1:rx 0 159079769 3639 irq260: em1:tx 0 153241788 3506 irq261: em1:link 2 0 irq262: ahci0 154747 3 cpu3:timer 33433174 764 cpu1:timer 36846475 843 cpu2:timer 38241059 874 Total 925258190 21170 [root@krynka ~]# ^C [root@krynka ~]# ^C [root@krynka ~]# [root@krynka ~]# vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 77, 8, 77, 0, 0 UMA Zones: 896, 0, 77, 3, 77, 0, 0 UMA Slabs: 568, 0, 3099, 2, 4537, 0, 0 UMA RCntSlabs: 568, 0, 7787, 4, 7787, 0, 0 UMA Hash: 256, 0, 1, 14, 3, 0, 0 16 Bucket: 152, 0, 137, 13, 137, 0, 0 32 Bucket: 280, 0, 174, 8, 174, 1, 0 64 Bucket: 536, 0, 150, 4, 150, 85, 0 128 Bucket: 1048, 0, 673, 2, 673, 531, 0 VM OBJECT: 216, 0, 51012, 702, 846817, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 190960, 48, 479, 138943, 0, 0 MAP ENTRY: 120, 0, 3995, 3104, 1720051, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 288, 62, 288, 0, 0 16: 16, 0, 2658, 702, 3383745, 0, 0 32: 32, 0, 3117, 1024,345727842, 0, 0 64: 64, 0, 14307, 1821, 1078924, 0, 0 128: 128, 0, 17324, 627, 1081728, 0, 0 256: 256, 0, 4057, 503, 855413, 0, 0 512: 512, 0, 1691, 199, 64092, 0, 0 1024: 1024, 0, 338, 186, 654647, 0, 0 2048: 2048, 0, 378, 172, 725396, 0, 0 4096: 4096, 0, 944, 380, 271793, 0, 0 Files: 80, 0, 628, 362, 1334639, 0, 0 TURNSTILE: 136, 0, 385, 75, 385, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 54, 93, 40402, 0, 0 THREAD: 1112, 0, 228, 156, 102099, 0, 0 SLEEPQUEUE: 80, 0, 385, 108, 385, 0, 0 VMSPACE: 392, 0, 37, 133, 40386, 0, 0 cpuset: 72, 0, 2, 98, 2, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 14192, 1168,783304841, 0, 0 mbuf: 256, 0, 7, 1538,1478688381, 0, 0 mbuf_cluster: 2048, 66560, 15360, 6, 15360, 0, 0 mbuf_jumbo_page: 4096, 33280, 0, 104, 85350, 0, 0 mbuf_jumbo_9k: 9216, 16640, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 8320, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 6192, 465621, 0, 0 ttyinq: 160, 0, 180, 180, 855, 0, 0 ttyoutq: 256, 0, 95, 130, 450, 0, 0 ata_request: 328, 0, 0, 0, 0, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 VNODE: 480, 0, 87998, 498, 673975, 0, 0 VNODEPOLL: 112, 0, 1, 65, 1, 0, 0 S VFS Cache: 108, 0, 64838, 28585, 841630, 0, 0 L VFS Cache: 328, 0, 24370, 254, 54085, 0, 0 NAMEI: 1024, 0, 0, 112, 4163219, 0, 0 DIRHASH: 1024, 0, 2035, 29, 2035, 0, 0 NCLNODE: 560, 0, 0, 0, 0, 0, 0 Mountpoints: 768, 0, 3, 52, 80, 0, 0 pipe: 728, 0, 6, 99, 26910, 0, 0 ksiginfo: 112, 0, 137, 919, 10321, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 21, 182, 12517, 0, 0 socket: 680, 66564, 562, 260, 356528, 0, 0 unpcb: 240, 66560, 16, 208, 227230, 0, 0 ipq: 56, 2142, 0, 0, 0, 0, 0 udp_inpcb: 392, 66560, 10, 160, 110510, 0, 0 udpcb: 16, 66696, 10, 830, 110510, 0, 0 tcp_inpcb: 392, 66560, 268, 122, 5007, 0, 0 tcpcb: 976, 66560, 267, 117, 5007, 0, 0 tcptw: 72, 13350, 1, 249, 463, 0, 0 syncache: 152, 15375, 0, 125, 4981, 0, 0 hostcache: 136, 15372, 47, 121, 374, 0, 0 tcpreass: 40, 4200, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 303, 142, 0, 0 ripcb: 392, 66560, 261, 159, 4708, 0, 0 rtentry: 200, 0, 265, 77, 696, 0, 0 selfd: 56, 0, 607, 842,234752684, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 87964, 388, 673517, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 87964, 371, 673517, 0, 0 NetGraph items: 72, 3074, 45, 419,408654662, 0, 0 NetGraph data items: 72, 522, 0, 406,753762645, 0, 0 sysctl dev.em: [root@krynka ~]# sysctl dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.RP05.PXSX dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.eee_control: 0 dev.em.0.link_irq: 21 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 375 dev.em.0.queue0.txd_tail: 380 dev.em.0.queue0.tx_irq: 233228570 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 1390 dev.em.0.queue0.rxd_tail: 1387 dev.em.0.queue0.rx_irq: 223537246 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 215 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 490098289 dev.em.0.mac_stats.good_pkts_recvd: 490098068 dev.em.0.mac_stats.bcast_pkts_recvd: 668 dev.em.0.mac_stats.mcast_pkts_recvd: 26234 dev.em.0.mac_stats.rx_frames_64: 30024908 dev.em.0.mac_stats.rx_frames_65_127: 158507333 dev.em.0.mac_stats.rx_frames_128_255: 52675194 dev.em.0.mac_stats.rx_frames_256_511: 6177207 dev.em.0.mac_stats.rx_frames_512_1023: 13887559 dev.em.0.mac_stats.rx_frames_1024_1522: 228825866 dev.em.0.mac_stats.good_octets_recvd: 358278813974 dev.em.0.mac_stats.good_octets_txd: 143854122957 dev.em.0.mac_stats.total_pkts_txd: 446863794 dev.em.0.mac_stats.good_pkts_txd: 446863793 dev.em.0.mac_stats.bcast_pkts_txd: 4491 dev.em.0.mac_stats.mcast_pkts_txd: 369 dev.em.0.mac_stats.tx_frames_64: 100198719 dev.em.0.mac_stats.tx_frames_65_127: 208003984 dev.em.0.mac_stats.tx_frames_128_255: 49443968 dev.em.0.mac_stats.tx_frames_256_511: 4556038 dev.em.0.mac_stats.tx_frames_512_1023: 9437320 dev.em.0.mac_stats.tx_frames_1024_1522: 75223765 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 21 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.0.wake: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.RP07.PXSX dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.1.%parent: pci3 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.eee_control: 0 dev.em.1.link_irq: 2 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1477444168 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 2697 dev.em.1.queue0.txd_tail: 2701 dev.em.1.queue0.tx_irq: 153936432 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 2002 dev.em.1.queue0.rxd_tail: 1995 dev.em.1.queue0.rx_irq: 159819215 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 17147 dev.em.1.mac_stats.xon_txd: 439 dev.em.1.mac_stats.xoff_recvd: 17147 dev.em.1.mac_stats.xoff_txd: 437 dev.em.1.mac_stats.total_pkts_recvd: 294811353 dev.em.1.mac_stats.good_pkts_recvd: 294777058 dev.em.1.mac_stats.bcast_pkts_recvd: 894201 dev.em.1.mac_stats.mcast_pkts_recvd: 108 dev.em.1.mac_stats.rx_frames_64: 5800926 dev.em.1.mac_stats.rx_frames_65_127: 165903195 dev.em.1.mac_stats.rx_frames_128_255: 33245720 dev.em.1.mac_stats.rx_frames_256_511: 4583201 dev.em.1.mac_stats.rx_frames_512_1023: 9693291 dev.em.1.mac_stats.rx_frames_1024_1522: 75550725 dev.em.1.mac_stats.good_octets_recvd: 139648048524 dev.em.1.mac_stats.good_octets_txd: 351097245622 dev.em.1.mac_stats.total_pkts_txd: 359659887 dev.em.1.mac_stats.good_pkts_txd: 359659011 dev.em.1.mac_stats.bcast_pkts_txd: 53290 dev.em.1.mac_stats.mcast_pkts_txd: 0 dev.em.1.mac_stats.tx_frames_64: 17921534 dev.em.1.mac_stats.tx_frames_65_127: 65738667 dev.em.1.mac_stats.tx_frames_128_255: 30554578 dev.em.1.mac_stats.tx_frames_256_511: 6857352 dev.em.1.mac_stats.tx_frames_512_1023: 13376498 dev.em.1.mac_stats.tx_frames_1024_1522: 225210382 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 2 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 0 dev.em.1.wake: 0 kldstat: [root@krynka ~]# kldstat Id Refs Address Size Name 1 27 0xffffffff80200000 1108818 kernel 2 1 0xffffffff81412000 1ba9 ng_socket.ko 3 10 0xffffffff81414000 8e12 netgraph.ko 4 1 0xffffffff8141d000 1861 ng_mppc.ko 5 1 0xffffffff8141f000 284 rc4.ko 6 1 0xffffffff81420000 aa5 ng_tee.ko 7 1 0xffffffff81421000 1b29 ng_pptpgre.ko 8 1 0xffffffff81423000 205d ng_ksocket.ko 9 1 0xffffffff81426000 138d ng_iface.ko 10 1 0xffffffff81428000 4605 ng_ppp.ko 11 1 0xffffffff8142d000 a29 ng_tcpmss.ko 12 1 0xffffffff8142e000 1bc0 ng_bpf.ko 13 1 0xffffffff81430000 13e5 ng_car.ko 14 1 0xffffffff81432000 c77 coretemp.ko P.S. Кто-нибудь знает как можно вернуть память из inact в free без перезагрузки? Edited November 13, 2012 by kosd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kosd Posted November 21, 2012 (edited) Free память почти вся перетекла уже в Inact. Так что завтра, скорее всего, сервак зависнет, как в прошлый раз (8-9 дней аптайма). last pid: 21869; load averages: 0.17, 0.23, 0.24 up 8+09:56:25 09:56:55 36 processes: 1 running, 35 sleeping CPU: 0.3% user, 0.0% nice, 2.1% system, 3.7% interrupt, 93.9% idle Mem: 351M Active, 2038M Inact, 630M Wired, 528K Cache, 415M Buf, 896M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 828 root 1 52 0 358M 281M select 1 91:31 0.00% mpd5 1162 freeradius 39 20 0 172M 76680K usem 3 44:15 0.00% radiusd 1129 mysql 17 20 0 728M 244M sbwait 2 35:59 0.00% mysqld 710 root 1 20 0 12184K 1632K select 2 1:12 0.00% syslogd 888 root 1 20 0 22332K 3400K select 2 0:23 0.00% ntpd 1163 root 1 20 0 202M 14188K select 2 0:10 0.00% httpd 1194 root 1 20 0 20384K 4304K select 1 0:05 0.00% sendmail 1187 root 1 20 0 46876K 4656K select 0 0:04 0.00% sshd 557 root 1 20 0 10372K 3488K select 3 0:03 0.00% devd 16083 www 1 22 0 202M 14528K lockf 2 0:02 0.00% httpd 1204 root 1 52 0 14260K 1720K nanslp 3 0:02 0.00% cron 97129 www 1 20 0 202M 14516K lockf 1 0:01 0.00% httpd 5169 www 1 20 0 202M 14536K lockf 2 0:01 0.00% httpd 5168 www 1 20 0 202M 14524K lockf 1 0:01 0.00% httpd 8008 www 1 24 0 202M 14500K lockf 2 0:01 0.00% httpd 98914 www 1 24 0 202M 14516K lockf 2 0:01 0.00% httpd 36718 www 1 22 0 202M 14508K lockf 2 0:01 0.00% httpd 64453 www 1 20 0 202M 14520K lockf 2 0:01 0.00% httpd 56182 www 1 20 0 202M 14508K lockf 2 0:00 0.00% httpd 69354 www 1 20 0 202M 14508K kqread 1 0:00 0.00% httpd 1198 smmsp 1 20 0 20384K 4156K pause 1 0:00 0.00% sendmail 15563 root 1 20 0 68016K 5544K select 0 0:00 0.00% sshd 15566 root 1 20 0 17580K 3060K wait 1 0:00 0.00% bash 1023 mysql 1 52 0 14636K 1936K wait 0 0:00 0.00% sh 21861 root 1 20 0 16700K 2344K CPU2 1 0:00 0.00% top 21856 dhcpd 1 20 0 16272K 6024K select 2 0:00 0.00% dhcpd 1272 root 1 52 0 12184K 1372K ttyin 0 0:00 0.00% getty 1266 root 1 52 0 12184K 1372K ttyin 2 0:00 0.00% getty 1268 root 1 52 0 12184K 1372K ttyin 1 0:00 0.00% getty 1271 root 1 52 0 12184K 1372K ttyin 0 0:00 0.00% getty 1270 root 1 52 0 12184K 1372K ttyin 3 0:00 0.00% getty 1265 root 1 52 0 12184K 1372K ttyin 3 0:00 0.00% getty 1269 root 1 52 0 12184K 1372K ttyin 1 0:00 0.00% getty 1267 root 1 52 0 12184K 1372K ttyin 2 0:00 0.00% getty 113 root 1 52 0 10060K 1212K pause 0 0:00 0.00% adjkerntz 535 root 1 52 0 14364K 1436K select 0 0:00 0.00% moused Уважаемые форумчане, подскажите, пожалуйста, как можно решить эту проблему? Edited November 21, 2012 by kosd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
terrible Posted November 21, 2012 снести нахер систему, поставить 8.3 и разобраться в серийных перезагрузках Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kosd Posted November 21, 2012 снести нахер систему, поставить 8.3 и разобраться в серийных перезагрузках Серийных перезагрузок я больше всего боюсь. Тогда на 8.3 доходило до того, что по 10-15 раз за вечер перезагружался. Хотя вначале почти месяц работало, потом серии по 3,4 перезагрузки раз в неделю. И там тоже память из free в inactive переходила. Перезагрузки вроде как прекратились после удаления netgraph из ядра. Ставил 8.3 на другое железо при тех же конфигах, сервер упал в этот же день после чего пришлось возвращаться на старый Gentoo+pptpd. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Hawk128 Posted November 21, 2012 Странное что-то у вас происходит. Прошел кучу версий с 7-х до 9-х, на всех НАСы трудятся бессбойно, за исключением IPv6. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zlolotus Posted November 22, 2012 Странное что-то у вас происходит. Прошел кучу версий с 7-х до 9-х, на всех НАСы трудятся бессбойно, за исключением IPv6. За год были два три ребута(из 4-х насов на каждом 600-700 абонентов), не думаю что это критично. Кстати Hawk128, платформа идентичная вашей, как-то вы писали. Минус, слишком мощный блок питания. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Hawk128 Posted November 22, 2012 Минус, слишком мощный блок питания. А в чем минус? Он расчитан на полную набивку. А потребляет столько сколько нужно... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...