OpenVZ Forum: Russian » Поведение процессов

Home » International » Russian » Поведение процессов

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Поведение процессов [message #24623]

Fri, 07 December 2007 01:20

atshellnick
Messages: 9
Registered: December 2007

Junior Member

День/вечер добрый!

Есть небольшая, но очень не приятная проблема, которая возможно вовсе и не связана с openvz, однако совета хочется испросить именно у вас.

Дело в том, что я собрал на базе OpenVZ web-сервер работающий под нагрузкой 30-40 тыс. хостов в день, до этого я делал подобное на джейлах бсд, однако решил попробывать OpenVZ. Вообщем изучил документацию, разобрался с базовыми приемами работы, настроил и запустил сервер на Gentoo/OpenVZ, перевел часть нагрузки и вообщем все очень даже работает и устраивает...

Однако, при попытке запустить "тяжелый" процесс внутри VE или даже на HW, получаю большие очереди Load Average по всему железному серверу, если такой процесс не завершить, то скопившиеся очередь валидных, рабочих процессов приводит к останову системы. Не подскажите почему такое происходит?

Под "тяжелым" процессом понимается развертывание дампа mysql сжатого gzip или например работа vzctl create 800 --ostemplate ...

Машина DL360G5; 2 x Quad Core 1,6Ghz; 6 GB RAM; HDD SATA.

В чем тут дело я недопонимаю... =(

PS:
Спасибо за OpenVZ, классная штука!

[Updated on: Fri, 07 December 2007 02:59]

Report message to a moderator

Re: Поведение процессов [message #24629 is a reply to message #24623]

Fri, 07 December 2007 04:37

kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia

Senior Member

Бинкаунтеры смотрели? Процессы в каком состоянии?

Kir Kolyshkin

http://static.openvz.org/userbars/openvz-developer.png

Report message to a moderator

Re: Поведение процессов [message #24644 is a reply to message #24623]

Fri, 07 December 2007 07:37

vaverin
Messages: 708
Registered: September 2005

Senior Member

Владимир,

В принципе для того чтобы разобраться чтобы разобраться в причинах надо смотреть где висят процессы в D-state (ps axl | grep " D"). далее смотреть за какой общий ресурс бьются эти процессы и думать как бы этот ресурс расшарить.
В Вашем случае скорее всего все встает на доступе к общему диску:
очевидно что и развертывание дампа и vzctl create много много пишут на диск. А если при этом рабочим процессам памяти начинает не хватать и они начинают активно swap юзать то ситуация еще более усугубляется.

К тому же я подозреваю что у вас файловая система смонтирована без опции noatime. Это приводит к тому что даже чтение файлов и директорий приводит к операциям записи (atime апдетится), При обилии процессов это само по седе серьезно нагружает диск.

Если все так и есть, то установка noatime сильно улучшит ситуацию.
Опцию можно установить на лету используя следующую комнду:
mount <mountpoint> -o remount,noatime

С уважением,
Василий Аверин

Report message to a moderator

Re: Поведение процессов [message #24784 is a reply to message #24629]

Mon, 10 December 2007 14:56

atshellnick
Messages: 9
Registered: December 2007

Junior Member

kir wrote on Thu, 06 December 2007 23:37

Бинкаунтеры смотрели? Процессы в каком состоянии?

Ага, /proc/user_beancounters вроде в порядке. Выставлял с запасом на перегрузки, значение failcnt не увеличивается при описанной ситуации.

Report message to a moderator

Re: Поведение процессов [message #24790 is a reply to message #24644]

Mon, 10 December 2007 15:57

atshellnick
Messages: 9
Registered: December 2007

Junior Member

Огромное спасибо за отклик!

1. Проверил noatime в fstab - присутствует на HN и в опциях монтирования внутри VPS. По mount видно:


/dev/cciss/c0d0p3 on / type ext3 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
/dev/cciss/c0d0p5 on /home type ext3 (rw,noatime)
/dev/cciss/c0d0p6 on /var type ext3 (rw,noatime)
/dev/cciss/c0d0p7 on /usr type ext3 (rw,noatime)
/dev/cciss/c0d0p8 on /vz type ext3 (rw,noatime)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)

...

2. Мысль насчет свопирования привела к обнаружению досадного ляпа, у меня был отключен high memory support в ядре при физических 6GB ОЗУ. После включения этой опции и перезагрузки сервера система обнаружила все 6GB, до этого она видела соотв. 4GB.

22:56:47@~ #-> free -m
             total       used       free     shared    buffers     cached
Mem:          6077       3239       2837          0        116       2332
-/+ buffers/cache:        791       5286
Swap:         7634          0       7634

Дистрибутив Gentoo 32-bit. Хотел сразу поставить 64-bit, но меня напугали тем, что в 64-битных релизах плохая поддержка драйверов.

3. После этого смоделировал ситуацию развертывания дампа и начал по вашему совету анализировать STATE и WCHAN.

NB!
Прежде всего хочу сказать, что сервер у меня поделен 6-ю VPS, один из которых выделен исключительно mysqld, в остальных работают форумы написанные на php, который работает модулем под Apache/2.0.58, который используется как backend к nginx.

Вообщем при развертывании дампа mysql получаю на HN, вот что:

ps axl | grep " D"


F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND

1    60 27286 26954  16   0 417032 125420 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 27296 26954  16   0 417032 125420 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 27388 26954  16   0 417032 125420 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 27447 26954  16   0 417032 125420 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29037 26954  18   0 416700 125300 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29072 26954  16   0 416700 125304 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29090 26954  18   0 416700 125304 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29101 26954  16   0 416700 125308 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29131 26954  17   0 416700 125324 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29140 26954  16   0 416700 125324 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29148 26954  17   0 416700 125324 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29182 26954  16   0 416700 125344 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29208 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29211 26954  18   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29216 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29219 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29220 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29223 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29248 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29279 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29302 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29305 26954  17   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29352 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29359 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29382 26954  16   0 416700 125428 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29465 26954  16   0 416700 125432 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29476 26954  18   0 416700 125432 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock
1    60 29497 26954  16   0 416700 125432 sync_p D   ?          0:00 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock

...

и т.д.

Вообщем как видно - они все встают в sync_p в столбце WCHAN.

И вот что это такое я не знаю =(

Системщики! =) Поделитесь тайными знаниями насчет понимания sync_p, в поиске по манам и в сети, толком ничего не нарыл.

PS:
Соотв. понятно почему сервер останавливается при этой операции, узкое место mysqld, надо наверно более тщательно выверять его настройки...

[Updated on: Mon, 10 December 2007 16:00]

Report message to a moderator

Re: Поведение процессов [message #24853 is a reply to message #24790]

Tue, 11 December 2007 11:57

vaverin
Messages: 708
Registered: September 2005

Senior Member

wchan показывает имя функции в ядре, где спит процесс.
так как ширина колонки в ps ограничена, то имя туда полностью не влезло. В принципе можно залезть в /proc/<pid>/wchan и прочитать там это имя целиком, однако и без того понятно что процессы вмсят на некоем sync, то есть пытаются параллельно писать на диск.

Почему тормозят -- не вполне понятно. 6 VE не так уж и много, и cciss по идее отнюдь не тормоз.

А Вы все mounts показали, или у Вас там еще какой-нить cifs/nfs смонтирован? Это может быть критично...

Относительно 64-bit хочу сказать, что зря Вас напугали. Нету в Linux с 64-bit драйверами никаких проблем, все нормально работает.

Report message to a moderator

Re: Поведение процессов [message #24897 is a reply to message #24853]

Tue, 11 December 2007 19:43

atshellnick
Messages: 9
Registered: December 2007

Junior Member

Собрал vzps и начал опять распаковывать нечто большое gunzip в контексте HN. Вот такие очереди теперь выстраиваются:
Причем в wchan стоит "-". Штатный ps тоже показывает "-" в wchan.

Добиться состояния "sync_p" теперь почему-то не получается. А очереди вырастают мгновенно, скачком до 15-20 процессов.

22:11:40@~ #-> vzps ax -o veid,pid,ppid,stat,comm,wchan | grep " D"
   0  4348    27 DW<  kjournald        sync_buffer
 800 10846 10845 D    nginx            sync_buffer
 800 10847 10845 D    nginx            -
 701 28676 27630 D    apache2          -
 701 28678 27630 D    apache2          -
 701 13177 13161 D    apache2          -
 701 13178 13161 D    apache2          -
 701 31728 31711 D    apache2          -
 701 31729 31711 D    apache2          -
 701 31733 31711 D    apache2          -
 701   531   522 D    apache2          -
 701   594   581 D    apache2          -
 701   599   581 D    apache2          -
 701  2909  2906 D    apache2          -
 701  2910  2906 D    apache2          -
 701  2915  2906 D    apache2          -
 701 12589 12580 D    apache2          -
 701 12590 12580 D    apache2          -
 701 12591 12580 D    apache2          -
 701 12642 12637 D    apache2          -
 701 12643 12637 D    apache2          -
 701 12649 12637 D    apache2          -
 701 12650 12637 D    apache2          -
 701 14718 14682 D    apache2          -
 701 19099 19096 D    apache2          -
 701 19103 19096 D    apache2          -
 701 19106 19096 D    apache2          -
 701 19220 19214 D    apache2          -
 701 19276 19262 D    apache2          -
 701 19278 19262 D    apache2          -
 701 19282 19262 D    apache2          sync_buffer
 701 19283 19262 D    apache2          -
 701 24886 24884 D    apache2          -
 701 24891 24884 D    apache2          -
 701 24894 24884 D    apache2          -
 701 27305 27299 D    apache2          -
 701 27310 27299 D    apache2          -
 701 28936 28934 D    apache2          -
 701 28943 28934 D    apache2          -
 701  4163  4157 D    apache2          -
 701  4167  4157 D    apache2          -
 701  4169  4157 D    apache2          -
 701  4180  4159 D    apache2          -
 701  4230  4227 D    apache2          -
 701  4232  4227 D    apache2          -
 701  4233  4227 D    apache2          -
 701  4234  4227 D    apache2          -
 701  4236  4227 D    apache2          -
 701  4239  4227 D    apache2          -
 701  4253  4243 D    apache2          -
 701  4268  4243 D    apache2          -
 701  4270  4247 D    apache2          -

В маунт поинтс я отрезал только подмонтированные gentoo portages к нескольким VPS (дерево пакетов, на всяк случай, пока идет "строительство" в VPS)

CIFS и NFS не используется на сервере.

701 - это как раз форум vBulletin - модули php под апаче. VPS в котором работает mysqld в этой серии экспериментов не проявлял себя в D-state.

Спасибо за информацию по 64-bit мне она тоже показалась абсурдной! Хотя я в таких тонкостях не разбираюсь.

[Updated on: Tue, 11 December 2007 19:58]

Report message to a moderator

Re: Поведение процессов [message #25078 is a reply to message #24897]

Fri, 14 December 2007 08:16

vaverin
Messages: 708
Registered: September 2005

Senior Member

"-" в wchan может вылезти из-за того что состояние процесса уже изменилось. Или когда адрес по каким-то причинам в имя функции оттранслировать не получается -- но в этом случае IMHO число должно выводиться. Может быть ps c "-n" таки сможет ядрес вывести, и по нему c помощью дампа ядра тоже можно до функции добраться.

Возможно Ваши процессы встают на page faults из-за нехватки памяти. И пока ядро память чистит они в висят D-state. Понаблюдайте за активностью swap в эти моменты.

Еще есть мысль -- проверить настройки CPU шедулятора. Возможно VE "переела" свою долю CPU. Или VE в cpulimit упирается. В этом случае ядро динамит процессы этой VE и отдает CPU в другие VE.

Вы юзаете CPULIMITS для VE на Вашей ноде? IMHO не стоит, но если таки юзаете, то проследите чтобы не cpulimits меньше 20% не ставились.

Или Ve0 чересчур малую долю CPU назначили. А поскольку там ранятся system-wide kernel threads им не дают достаточного количества ресурсов для нормального решения system-wide задач.

Проверьте CPUUNITS для VE0 (vzcpucheck -v), VE0cpuunits должн в несколько раз превышать VE's cpuunits.

С уважением,
Василий Аверин

Report message to a moderator

Re: Поведение процессов [message #25209 is a reply to message #25078]

Mon, 17 December 2007 20:29

atshellnick
Messages: 9
Registered: December 2007

Junior Member

Огромное спасибо за подсказку!
Кажеться я понял как исправлять ситуацию.

CPULIMITS - не использую. Вместо него выставляю для VE - CPUUNITS.

Действительно!!! VE0, стоял у меня в CPUUNITS=1000 (это дефолтное значение /etc/conf.d/vz для дистрибутива Gentoo Linux) Какого его истиное значение - я и не догадывался Smile

Как только я начал управлять этим значением - система стала более предсказуемой. От возникновения очередей я сейчас избавиться не смог =(, но зато при помощи vzps видно в каких VE получаются эти самые очереди. Буду искать вообщем где у меня тонкое место. Надеюсь найду...

У меня вот вопрос. Могу я ли распределять ресурсы так, чтобы у меня был overcommited? Дикий конечно на первый взгляд вопрос и политика распределения ресурсов CPUUNITS. Но таким образом я стремлюсь получить от OpenVZ некий QoS в стиле *отдай ресурс CPU другого VE если текущий VE выбрал свой лимит, а у других его навалом и они его не используют в данный момент*

Вот! =) Возможно это как-то по другому можно сделать.

23:05:52@~ #-> vzcpucheck -v
vpsid           units
-----------------------
0               500000
800             500000
701             500000
Current CPU utilization: 1500000
Power of the node: 752678
Warning: hardware node is overcommited

Report message to a moderator

Re: Поведение процессов [message #25224 is a reply to message #25209]

Tue, 18 December 2007 05:42

vaverin
Messages: 708
Registered: September 2005

Senior Member

CPUUMITS -- это относительная величина, ее надо рассматривать как вес VE. По CPUUNITS определяется fair share CPU для VE, и VE может рассчитывать, что эту свою fair share она получит всегда, даже на полностью загруженной ноде.
Если на ноде есть свободный ресурс -- то VE может его использовать.
Если же VE свою долю не использует -- этот ресурс будут использовать другие VE.

Примеры: 2 VE c одинаковым весом + VE0, все активно работают
VE0 = VEx = VEy
fair share каждой VE -- 1/3, то есть каждая VE получит треть процессорного времени.
Теперь пусть одна из VE свою задачу выполнила и перестала потреблять CPU. В этом случае остальные VE станут получать по 1/2 CPU.
Теперь вторая VE тоже все сделала и CPU ей тоже больше не нужен -- в этом случае оставшаяся VE сможет юзать все процессорное время.

Однако тут надо отметить следующий момент: В VE0 ранятся системные треды: kjournald, kswapd и другие. Эти треды обеспечивают нормльную работоспособность всей системы -- пишут на диск, память чистят. Если этим процессам не давать CPU для решения этих задач -- встанет вся система: процессы внутри VE будут ждать пока им почистят память, а память чистится медленно потому что kswapd не дают CPU.

Поэтому вес VE0 должен быть в несколько раз выше веса самой крупной VE. Отчасти по этой причине мы не рекомендуем оставлять какие-либо тяжелые процессы в VE0.

Для fair share абсолютная велчина CPUunits не важна, ваджно соотоношение этих величин назначенных для VE.
то есть можно поставить всем по 100 cpuunits, можно по 1000, можно по 10000. главное -- соблюсти требуемую пропорцию между VE.

А абсолютная величина CPUunits может быть полезна в следующем случае: если его поделить на Power of the node (которое как-то пересчитывается из bogomips, то есть как-то зависит от мощности CPU на ноде), пересчитать эту гарантию в мегагерцы и говорить о ней клиентам. Клиенты плохо понимают cpuunits, но всегда интересуются мегагерцами Smile

поэтому owercommit по cpuunits не страшен, разве что Вам гарантию в мегагерцы придется пересчитывать несколько по более "неудобной" формуле -- и что наиболее важно гарантия изменится когда вы поднимите на этой ноде еще одну VE.

С уваженеим,
Василий Аверин

Report message to a moderator

Re: Поведение процессов [message #25323 is a reply to message #25224]

Thu, 20 December 2007 14:05

atshellnick
Messages: 9
Registered: December 2007

Junior Member

Василий, большой респект и уважуха! =)

Report message to a moderator

Previous Topic:	Resolved Failcnt увеличивается, хотя maxheld<barrier
Next Topic:	Разные возможности iptables в VE.i386 на нодах i386 и X86_64

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Fri May 03 23:55:25 GMT 2024

Total time taken to generate the page: 0.01741 seconds