Sunday, 31 January 2010
OpenVZ, TCP: time wait bucket table overflow
Столкнулись с такой проблемой в dmesg:
Среди возможной причины предполагаем огромное число TIME_WAIT соединений:
Вот один из вариантов фикса от Red Hat: http://kbase.redhat.com/faq/docs/DOC-1253
Как я понял, число TIME WAIT можно увеличить, увеличив следующую переменную:
Увеличим вдвое:
Предположительно, проблема решилась (ну или просто мессаджи перестали сыпаться в dmesg) :)
TCP: time wait bucket table overflow
Среди возможной причины предполагаем огромное число TIME_WAIT соединений:
netstat -npt | grep TIME_WAIT | wc -l
710
Вот один из вариантов фикса от Red Hat: http://kbase.redhat.com/faq/docs/DOC-1253
Как я понял, число TIME WAIT можно увеличить, увеличив следующую переменную:
cat /proc/sys/net/ipv4/tcp_max_tw_buckets
720000
Увеличим вдвое:
echo 1440000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
Предположительно, проблема решилась (ну или просто мессаджи перестали сыпаться в dmesg) :)
Как в мультипроцессорной системе перенести обработку прерываний eth на другое ядро?
Имеем такую картину:
eth0 соответствует 82 прерывание и все они обрабатываются 1м ядром.
Переносим обработку прерываний на 4-8е ядра:
Смотрим результат:
Ну и результат:
(с) http://www.ibm.com/developerworks/ru/library/l-scalability/index.html
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 524 0 0 1797756799 0 0 0 0 IO-APIC-edge timer
1: 0 0 0 968 0 0 0 0 IO-APIC-edge i8042
8: 0 0 0 0 0 0 3 0 IO-APIC-edge rtc
9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi
12: 4 0 0 0 0 0 0 0 IO-APIC-edge i8042
50: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3
58: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb4
66: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb5, uhci_hcd:usb7
74: 2230577823 0 0 0 0 0 0 0 PCI-MSI ahci
82: 97331448 0 0 0 0 0 0 0 PCI-MSI eth0
225: 0 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb8
233: 0 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb2, uhci_hcd:usb6
NMI: 0 0 0 0 0 0 0 0
LOC: 1747868310 1788131037 1787952568 1797756803 1788681699 1790209706 1788657167 1790195713
ERR: 0
MIS: 0
eth0 соответствует 82 прерывание и все они обрабатываются 1м ядром.
cat /proc/irq/82/smp_affinity
ffffffff
Чтобы привязать прерывание к процессору или группе процессоров, сначала нужно определить, какой процессор должен обрабатывать прерывание, и соответствующим образом задать битовую маску. Крайний справа бит маски устанавливается для CPU0, следующий для CPU1 и так далее. Для обозначения группы процессоров можно установить несколько битов. После этого задайте значение битовой маски, выполнив следующую команду:
echo bitmask > /proc/irq/IRQ_number/smp_affinity
Например, чтобы привязать обработку прерывания номер 177 к процессорам с 4 по 7 (битовая маска 11110000), выполните:
echo f0 > /proc/irq/177/smp_affinity
Переносим обработку прерываний на 4-8е ядра:
echo f0 > /proc/irq/82/smp_affinity
Смотрим результат:
cat /proc/irq/82/smp_affinity
000000f0
Ну и результат:
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 524 0 0 1798224886 0 0 0 0 IO-APIC-edge timer
1: 0 0 0 968 0 0 0 0 IO-APIC-edge i8042
8: 0 0 0 0 0 0 3 0 IO-APIC-edge rtc
9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi
12: 4 0 0 0 0 0 0 0 IO-APIC-edge i8042
50: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3
58: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb4
66: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb5, uhci_hcd:usb7
74: 2230694661 0 0 0 0 0 0 0 PCI-MSI ahci
82: 97820891 0 0 0 74684 0 0 0 PCI-MSI eth0
225: 0 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb8
233: 0 0 0 0 0 0 0 0 IO-APIC-level ehci_hcd:usb2, uhci_hcd:usb6
NMI: 0 0 0 0 0 0 0 0
LOC: 1748336398 1788599125 1788420656 1798224891 1789149787 1790677794 1789125255 1790663801
ERR: 0
MIS: 0
(с) http://www.ibm.com/developerworks/ru/library/l-scalability/index.html
Saturday, 30 January 2010
Сменить пароль для юзера VDSManager из консоли
passwd=`pwgen 16 1`; username=admin; echo $passwd ; /usr/local/ispmgr/sbin/mgrctl -m vdsmgr user.edit name=$username level=admin sok=ok passwd=$passwd elid=$username
Как CRON исполняет процессы от имени пользователя?
Смена uid/gid происходит посредством setgid():
[pid 5591] read(5,
[pid 5593] <... stat resumed> {st_mode=S_IFREG|0644, st_size=2194, ...}) = 0
[pid 5593] getpid() = 5593
[pid 5593] sendto(7, "<78>Jan 30 19:27:01 /USR/SBIN/CRO"..., 59, MSG_NOSIGNAL, NULL, 0) = 59
[pid 5593] close(7) = 0
[pid 5593] setsid() = 5593
[pid 5593] close(4) = 0
[pid 5593] close(5) = 0
[pid 5593] dup2(3, 0) = 0
[pid 5593] dup2(6, 1) = 1
[pid 5593] dup2(1, 2) = 2
[pid 5593] close(3) = 0
[pid 5593] close(6) = 0
[pid 5593] setgid(1001) = 0
[pid 5593] open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3
Friday, 29 January 2010
Catalyst: конфигурация модели
Сабж довольно частый -- очень удобно иметь единый конфиг, а не размазаный по десятку модулей. Сходя найти решение "как передать конфигу в модель" не нашёл, но спас Гугл: http://blog.jrock.us/articles/Catalyst%20Tips:%20Part%201.pod
Пишем простейший фильтр исходных кодов
Вот сегодня на очередном совещании по работе мне напомнили про такую суперскую вещь как "фильтры исходных кодов"; я давно хотел их попробовать, но постоянно забывал, что же! Пора =)
Исходный код вот:
Запускаем:
Уж и стоит ли мне говорить, что посредством такого супердвижка можно легко написать на Перле свой ДЯП ?)
пысы: кого воткнуло, идём читать: http://perldoc.perl.org/perlfilter.html
Исходный код вот:
package MyFilter;
use Filter::Util::Call;
sub import {
my ($type) = @_;
my ($ref) = [];
filter_add(bless $ref);
}
sub filter {
my ($self) = @_;
my ($status);
s/"([a-zA-Z]+)"/"uc $1"/eg
if ($status = filter_read()) > 0;
$status;
}
1;
Запускаем:
perl -MMyFilter -e 'print "AaAaaaA"'
AAAAAAA
Уж и стоит ли мне говорить, что посредством такого супердвижка можно легко написать на Перле свой ДЯП ?)
пысы: кого воткнуло, идём читать: http://perldoc.perl.org/perlfilter.html
О $c->model
В документации по Каталисту на Цпане сказано:
Обращаем внимание на последний пункт по причине, что он нифига не работает, т.е. чтобы обращаться по $c->model() (вместо $c->model('MyModelName')) надо ОБЯЗАТЕЛЬНО вписать в конфиг параметр default_model: VashModel и только после этого оно заработает. Так понимаю, это бага.
If the name is omitted, it will look for - a model object in $c->stash->{current_model_instance}, then - a model name in $c->stash->{current_model}, then - a config setting 'default_model', or - check if there is only one model, and return it if that's the case.
Обращаем внимание на последний пункт по причине, что он нифига не работает, т.е. чтобы обращаться по $c->model() (вместо $c->model('MyModelName')) надо ОБЯЗАТЕЛЬНО вписать в конфиг параметр default_model: VashModel и только после этого оно заработает. Так понимаю, это бага.
Как создать объект, конструируемый на этапе старта Каталиста
Как создать объект конструируемый на этапе старта Каталиста, который потом использовался всеми контроллерами до окончания работы Каталиста ? А вот так: http://community.livejournal.com/ru_catalyst/9867.html
И вопрос и ссылка заимствованы с вышеуказанного урла.
И вопрос и ссылка заимствованы с вышеуказанного урла.
Перенос PAR пэкаджа с 32 битной на 64 битную платформу
Я уже говорил, что PAR кроме pm модулей на чистом Перле складывает в свой архив .so расширения, и обещался провести эксперимент переноса рабочего приложения с 32 битной на 64 битную платформу.
Внимание, рабочая машинка имеет конфу (сервер, никаких спец модулей для Perl нету):
2.6.18-ovz-smp-alt14 #1 SMP Wed May 2 15:41:34 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux
девелоперская:
Linux nrg-desktop 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 i686 GNU/Linux
Как собрать PAR пэкадж я уже говорил в http://perlaround.blogspot.com/2009/03/par-catalyst.html, сейчас обсудим комплекс мер по подготовке второй системы к приёму пэкадажа :)
Ставим PAR: sudo cpan PAR PAR::Packer (возможно, PAR::Packer придётся ставить через cpan force).
Переливаем пэкадж на новую машину каким-то образом (я предпочитаю sftp, т.к. он сходу работает в Гноме).
Запускаем и обламываемся:
Как вариант, можно попробовать собрать в Пэкадж ещё и сам Перл интерпретатор (дада, вы не ослышались!), делается это так pp -o имя_нового_пэкаджа_с_перлом catapp_server.par, но в моём случае это тоже не помогло.
Что же, пока принимаю поражение, но не сдаюсь.
Добавление: вообще, вариант проблему решить посредством виртулизации, например, на qemu -- т.е. собрать дистрибутив, в котором будет 1) ядро ОС 2) Перл 3) Всё необходимое для пуска Перла и в таком виде его раздавать :) Но тут возникает ещё большая куча проблем -- как быть с диском для виртулки, как работать с сетью и проч. Так что тоже для мелочи не вариант.
Часть инфы взята из: http://catalyst.infogami.com/cookbook/par
Внимание, рабочая машинка имеет конфу (сервер, никаких спец модулей для Perl нету):
2.6.18-ovz-smp-alt14 #1 SMP Wed May 2 15:41:34 MSD 2007 x86_64 x86_64 x86_64 GNU/Linux
девелоперская:
Linux nrg-desktop 2.6.24-22-generic #1 SMP Mon Nov 24 18:32:42 UTC 2008 i686 GNU/Linux
Как собрать PAR пэкадж я уже говорил в http://perlaround.blogspot.com/2009/03/par-catalyst.html, сейчас обсудим комплекс мер по подготовке второй системы к приёму пэкадажа :)
Ставим PAR: sudo cpan PAR PAR::Packer (возможно, PAR::Packer придётся ставить через cpan force).
Переливаем пэкадж на новую машину каким-то образом (я предпочитаю sftp, т.к. он сходу работает в Гноме).
Запускаем и обламываемся:
Can't load '/tmp/par-nrg/cache-e463425e9fd4743fd99b42ffc3b1f2aee266f2aa/2b152795.so' for module HTML::Parser: /tmp/par-nrg/cache-e463425e9fd4743fd99b42ffc3b1f2aee266f2aa/2b152795.so: неправильный класс ELF: ELFCLASS32 at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
at /usr/lib/perl5/site_perl/5.8.8/PAR/Heavy.pm line 109
Compilation failed in require at HTML/Entities.pm line 147.
Compilation failed in require at Catalyst/Engine.pm line 8.
BEGIN failed--compilation aborted at Catalyst/Engine.pm line 8.
Compilation failed in require at (eval 19) line 3.
...propagated at /usr/lib/perl5/5.8.8/base.pm line 85.
BEGIN failed--compilation aborted at Catalyst/Engine/CGI.pm line 4.
Compilation failed in require at (eval 18) line 3.
...propagated at /usr/lib/perl5/5.8.8/base.pm line 85.
BEGIN failed--compilation aborted at Catalyst/Engine/HTTP.pm line 4.
Compilation failed in require at ./script/catapp_server.pl line 9.
BEGIN failed--compilation aborted at ./script/catapp_server.pl line 10.
Как вариант, можно попробовать собрать в Пэкадж ещё и сам Перл интерпретатор (дада, вы не ослышались!), делается это так pp -o имя_нового_пэкаджа_с_перлом catapp_server.par, но в моём случае это тоже не помогло.
Что же, пока принимаю поражение, но не сдаюсь.
Добавление: вообще, вариант проблему решить посредством виртулизации, например, на qemu -- т.е. собрать дистрибутив, в котором будет 1) ядро ОС 2) Перл 3) Всё необходимое для пуска Перла и в таком виде его раздавать :) Но тут возникает ещё большая куча проблем -- как быть с диском для виртулки, как работать с сетью и проч. Так что тоже для мелочи не вариант.
Часть инфы взята из: http://catalyst.infogami.com/cookbook/par
Сборка PAR пэкаджа для Catalyst приложения
Как известно, Каталист имеет туеву кучу зависимостей и развернуть его на системе, где разработка на перле производится впервые довольно проблематично и может вылиться часа в 3 времени, решение задачи довольно очевидно -- собрать все нужные модули и засунуть в архив вместе с аппликацией. Впрочем, так и поступает PAR (Perl Archive Toolkit), их офсайт тут: http://par.perl.org
Но, как многие могли догадаться, проблем мы огребём по полной в случае завязывания приложения на XS модули, которые, во-первых, не так легко перетащить, а во-вторых, не так легко заставить работать под разными платформами (у меня, например, рабочая машинка 32 битная, а почти все на работе -- 64 битные). Но на наше счастье, Каталист не требует XS расширений (разве что опциональное XS Stash для Template Toolkit). Ладно, давайте проверим PAR в деле, а там разберемся, какие проблемы вылезут.
Ставим сам PAR: sudo cpan PAR PAR::Packer
Собираем пэкадж: переходим в папку с нашим Каталист проектом и вызываем: perl Makefile.PL после этого запускаем make catalyst_par и ждём, пока Пэкадж соберётся.
Следовало бы заметить, что PAR пэкадж запустится далеко не на любой системе, по крайней мере нам будет нужен Perl и сам PAR (в идеале, конечно же, было бы заиметь его в менеджере пакетов, тогда развертывание Перл приложений вообще превратилось в нечто сверх банальное).
Не знаю как у вас, но у меня PAR пэкадж собрался и весит 1,7 мегабайта, что же, попробуем его запустить! Для запуска используется программа "parl" (отличие от "perl" во второй букве), ну что пускаем!
После запуска видим нечто вот такое:
Как подсказывает хелп, пускать надо вот так: parl catalystapp.par catalystapp_server.pl -p 80, делаем это и вуаля! Каталист аппликация пустилась и отлично работает! =)
Ну что же, попробую сейчас сделать наконец-то таки панель для нашего хостинга и проверить её развертывание таким образом.
Да, кстати, по поводу огребания от XS -- PAR складывает .so модули в папочку по имени /lib/auto/ (папочку?! да, вы угадали, PAR -- это обычный архив). Вот интересный вопрос будет, что произойдёт при запуске на платформе другой архитектуры, что же, это мы попробуем прямо сейчас, но опишу в другом посте.
Но, как многие могли догадаться, проблем мы огребём по полной в случае завязывания приложения на XS модули, которые, во-первых, не так легко перетащить, а во-вторых, не так легко заставить работать под разными платформами (у меня, например, рабочая машинка 32 битная, а почти все на работе -- 64 битные). Но на наше счастье, Каталист не требует XS расширений (разве что опциональное XS Stash для Template Toolkit). Ладно, давайте проверим PAR в деле, а там разберемся, какие проблемы вылезут.
Ставим сам PAR: sudo cpan PAR PAR::Packer
Собираем пэкадж: переходим в папку с нашим Каталист проектом и вызываем: perl Makefile.PL после этого запускаем make catalyst_par и ждём, пока Пэкадж соберётся.
Следовало бы заметить, что PAR пэкадж запустится далеко не на любой системе, по крайней мере нам будет нужен Perl и сам PAR (в идеале, конечно же, было бы заиметь его в менеджере пакетов, тогда развертывание Перл приложений вообще превратилось в нечто сверх банальное).
Не знаю как у вас, но у меня PAR пэкадж собрался и весит 1,7 мегабайта, что же, попробуем его запустить! Для запуска используется программа "parl" (отличие от "perl" во второй букве), ну что пускаем!
После запуска видим нечто вот такое:
parl catalystapp.par
Usage:
[parl] catalystapp[.par] [script] [arguments]
Examples:
parl catalystapp.par catalystapp_server.pl -r
myapp catalystapp_cgi.pl
Available scripts:
catalystapp_cgi.pl
catalystapp_create.pl
catalystapp_fastcgi.pl
catalystapp_server.pl
catalystapp_test.pl
Как подсказывает хелп, пускать надо вот так: parl catalystapp.par catalystapp_server.pl -p 80, делаем это и вуаля! Каталист аппликация пустилась и отлично работает! =)
Ну что же, попробую сейчас сделать наконец-то таки панель для нашего хостинга и проверить её развертывание таким образом.
Да, кстати, по поводу огребания от XS -- PAR складывает .so модули в папочку по имени /lib/auto/ (папочку?! да, вы угадали, PAR -- это обычный архив). Вот интересный вопрос будет, что произойдёт при запуске на платформе другой архитектуры, что же, это мы попробуем прямо сейчас, но опишу в другом посте.
Создание собственных модулей для CPAN
Я создаю новые каркасы модулей следующей командой: h2xs --omit-XS --omit-autoload --force --version=0.01 --compat-version=5.8.8 --name Google::Charts1
В результате будет создана следующая структура:
Сходу два недостатка: всё завязывается на Exporter + не генерируется привычный многим Build.PL.
А есть ли аналоги? Конечно! http://search.cpan.org/~jkeenan/ExtUtils-ModuleMaker-0.51/lib/ExtUtils/ModuleMaker.pm
Но модуль нестандартный, поэтому его надо поставить: sudo cpan ExtUtils::ModuleMaker и изучить самостоятельно :)
В результате будет создана следующая структура:
Writing Google-Charts1/lib/Google/Charts1.pm
Writing Google-Charts1/Makefile.PL
Writing Google-Charts1/README
Writing Google-Charts1/t/Google-Charts1.t
Writing Google-Charts1/Changes
Writing Google-Charts1/MANIFEST
Сходу два недостатка: всё завязывается на Exporter + не генерируется привычный многим Build.PL.
А есть ли аналоги? Конечно! http://search.cpan.org/~jkeenan/ExtUtils-ModuleMaker-0.51/lib/ExtUtils/ModuleMaker.pm
To create a distribution containing only Perl code. ExtUtils::ModuleMaker is intended to be an easy-to-use replacement for this use of h2xs.
Но модуль нестандартный, поэтому его надо поставить: sudo cpan ExtUtils::ModuleMaker и изучить самостоятельно :)
Создание и запуск простейшего Catalyst приложения
Ну тут всё банально донельзя:
И после этого встроенный сервер Каталиста будет запущен, в чём можно убедиться, открыв в браузере страницу: http://127.0.0.1
catalyst.pl my_test_catalyst_app
cd my_test_catalyst_app/
script/my_test_catalyst_app_server.pl -reload -p 80
И после этого встроенный сервер Каталиста будет запущен, в чём можно убедиться, открыв в браузере страницу: http://127.0.0.1
Установка Perl фреймворка Catalyst на Debian 5 Lenny с Perl 5.10
Сначала ставим сам CPAN:
Теперь поставим всё необходимое для сборки XS модулей (написанных на С) и в т.ч.команду make:
Обновим сам CPAN:
Теперь обновим все Perl модули, имеющиеся в системе:
У меня не обновились лишь следующие модули, но т.к. я их не использую, мне это не интересно:
Ну и, наконец, поставим сам Catalyst:
Не знаю, как у Вас, но у меня не встал лишь модуль: Catalyst::Plugin::Session::State::URI
Который придётся поставить насильно:
После этого надо повторить команды, которые мы использовали для установки Каталиста.
В итоге нас должна встретить вот такая прелестная надпись:
Попутно возникла идея сделать свой аналог http://search.cpan.org/~mramberg/Task-Catalyst-3.0000/lib/Task/Catalyst.pm куда включить наиболее часто используемые, на мой взгляд, модули. Причем, как и ожидалось, пакетная инсталляция там решаться через толстый Makefile.PL :)
apt-get install perl
Теперь поставим всё необходимое для сборки XS модулей (написанных на С) и в т.ч.команду make:
apt-get install gcc make
Обновим сам CPAN:
cpan YAML Bundle::CPAN
Теперь обновим все Perl модули, имеющиеся в системе:
cpan
cpan_shell: upgrade
У меня не обновились лишь следующие модули, но т.к. я их не использую, мне это не интересно:
DB_File 1.816_1 1.819 PMQS/DB_File-1.819.tar.gz
B 1.17 1.19 NWCLARK/perl-5.8.9.tar.gz
Ну и, наконец, поставим сам Catalyst:
cpan Task::Catalyst Catalyst::Devel
Не знаю, как у Вас, но у меня не встал лишь модуль: Catalyst::Plugin::Session::State::URI
Который придётся поставить насильно:
cpan
cpan_shell: force install Catalyst::Plugin::Session::State::URI
После этого надо повторить команды, которые мы использовали для установки Каталиста.
В итоге нас должна встретить вот такая прелестная надпись:
Task::Catalyst is up to date (3.0000).
Catalyst::Devel is up to date (1.10)
Попутно возникла идея сделать свой аналог http://search.cpan.org/~mramberg/Task-Catalyst-3.0000/lib/Task/Catalyst.pm куда включить наиболее часто используемые, на мой взгляд, модули. Причем, как и ожидалось, пакетная инсталляция там решаться через толстый Makefile.PL :)
Увеличить таймауты ожидания ответа Proxy в Nginx
Необходимо добавить в блок http следующее:
proxy_read_timeout 1800;
proxy_send_timeout 1800;
Debian: удобный chroot
Для многого софта необходимо чтобы в chroot были /dev, /proc, /sys. Обычно это делается вручную, но на Debian есть более простой способ, простенький скрипт:
После чего:
Теперь чрутимся:
Выходить из чрута в обратном порядке:
А вот сам скрипт:
chroot-prepare /mnt
После чего:
mount
/proc on /mnt/proc type none (rw,bind)
/sys on /mnt/sys type none (rw,bind)
/dev on /mnt/dev type none (rw,bind)
Теперь чрутимся:
chroot /mnt
Выходить из чрута в обратном порядке:
umount /mnt/proc
umount /mnt/dev
umount /mnt/sys
umount /mnt
А вот сам скрипт:
#!/bin/bash
mount --bind /dev /mnt/dev/
mount --bind /proc /mnt/proc/
mount --bind /sys /mnt/sys/
Установка webgrind
После работы xdebug в режиме профайлера в /tmp появляется огромное число его файлов данных, которые вручную обрабатывать почти нереально:
В этом нам поможет webgrind:
Cтавим его:
После этого заходим на свой сервер: http://test1.ru/webgrind/ и выбираем в списке в верху необходимый файл и выбираем update. Теперь ждем пока построится отчет и обращаем основное внимание на столбец "total inclusive cost", который показывает, сколько процентов времени работы было потрачено на исполнение указанной функции.
ls -la /tmp
-rw-r--r-- 1 default default 95M 2010-01-29 20:01 cachegrind.out.27788
-rw-r--r-- 1 default default 95M 2010-01-29 20:01 cachegrind.out.27789
-rw-r--r-- 1 default default 89M 2010-01-29 20:01 cachegrind.out.27793
-rw-r--r-- 1 default default 91M 2010-01-29 20:01 cachegrind.out.27794
-rw-r--r-- 1 default default 88M 2010-01-29 20:02 cachegrind.out.27795
-rw-r--r-- 1 default default 91M 2010-01-29 20:01 cachegrind.out.27796
-rw-r--r-- 1 default default 88M 2010-01-29 20:01 cachegrind.out.27797
-rw-r--r-- 1 default default 91M 2010-01-29 20:01 cachegrind.out.27798
-rw-r--r-- 1 default default 15M 2010-01-29 20:02 cachegrind.out.27940
-rw-r--r-- 1 default default 16M 2010-01-29 20:02 cachegrind.out.27941
-rw-r--r-- 1 default default 16M 2010-01-29 20:02 cachegrind.out.27942
-rw-r--r-- 1 default default 16M 2010-01-29 20:02 cachegrind.out.27943
-rw-r--r-- 1 default default 16M 2010-01-29 20:02 cachegrind.out.27944
-rw-r--r-- 1 default default 15M 2010-01-29 20:02 cachegrind.out.27945
-rw-r--r-- 1 default default 16M 2010-01-29 20:02 cachegrind.out.27946
-rw-r--r-- 1 default default 15M 2010-01-29 20:02 cachegrind.out.27947
В этом нам поможет webgrind:
Cтавим его:
cd /var/www
wget http://webgrind.googlecode.com/files/webgrind-release-1.0.zip
unzip webgrind-release-1.0.zip
После этого заходим на свой сервер: http://test1.ru/webgrind/ и выбираем в списке в верху необходимый файл и выбираем update. Теперь ждем пока построится отчет и обращаем основное внимание на столбец "total inclusive cost", который показывает, сколько процентов времени работы было потрачено на исполнение указанной функции.
Чем занимается CMS Wordpress во время исполнения?
Ставим стандартный Wordpress на сервер с Nginx/Apache2/PHP FastCGI и прогоняем 1000 запросов в 10 потоков (суммарно выходит 10 000 запросов). Получаем следующие цифры:
При этом MySQL аккаунтинг показывает следующие цифры
То есть в среднем 1 открытие блога выходит 1 соединение с MySQL, 17 килобайт чтения с БД, 2 select запроса, чтение 8 строк с таблиц.
Но вот исходной задачи - узнать, какую часть времени движок тратит на работу с БД я так и не решил. Вот, похоже как это решать правильно: http://codex.wordpress.org/Testing_WordPress_Performance
ab -c 10 -n 10000 http://test1.ru:80/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking test1.ru (be patient)
Completed 1000 requests
...
Finished 10000 requests
Server Software: nginx
Server Hostname: test1.ru
Server Port: 80
Document Path: /
Document Length: 4965 bytes
Concurrency Level: 10
Time taken for tests: 215.649745 seconds
Complete requests: 10000
Failed requests: 16
(Connect: 0, Length: 16, Exceptions: 0)
Write errors: 0
Non-2xx responses: 16
Total transferred: 51509264 bytes
HTML transferred: 49579184 bytes
Requests per second: 46.37 [#/sec] (mean)
Time per request: 215.650 [ms] (mean)
Time per request: 21.565 [ms] (mean, across all concurrent requests)
Transfer rate: 233.26 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 74.2 0 3032
Processing: -2873 217 936.8 167 46218
Waiting: 0 218 933.3 166 46218
Total: 0 219 933.8 167 46218
Percentage of the requests served within a certain time (ms)
50% 167
66% 170
75% 172
80% 173
90% 176
95% 179
98% 184
99% 843
100% 46218 (longest request)
При этом MySQL аккаунтинг показывает следующие цифры
Total_connections 9984
Connected_time 1517
Busy_time 10
Cpu_time 11
Bytes_received 23 783 628
Bytes_sent 179 513 360
Rows_fetched 83415
Rows_updated 8
Table_rows_read 223534
Select_commands 20253
То есть в среднем 1 открытие блога выходит 1 соединение с MySQL, 17 килобайт чтения с БД, 2 select запроса, чтение 8 строк с таблиц.
Но вот исходной задачи - узнать, какую часть времени движок тратит на работу с БД я так и не решил. Вот, похоже как это решать правильно: http://codex.wordpress.org/Testing_WordPress_Performance
Удаленный MySQL vs локальный
Тесты полная синтетика, кто скажет, что они ацтой - будет прав. На таргет машине голый вордпресс. Канал между машинами - 100 магабит череpз 3 хопа. Долбеж ведется посредством ab в такой конфигурации: ab -c 10 -n 1000 http://test1.ru:80/
Результаты тестов следующие:
Локальный:
Удаленный без тюнинга:
Удаленный с тюнингом:
Результаты тестов следующие:
Локальный мускул: Requests per second: 55.36 [#/sec] (mean)
Удаленный (без тюнинга - стандартный CentOS MySQL): Requests per second: 44.23 [#/sec] (mean)
Удаленный (с тюнингом): Requests per second: 46.40 [#/sec] (mean)
Локальный:
ab -c 10 -n 1000 http://test1.ru:80/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking test1.ru (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: nginx
Server Hostname: test1.ru
Server Port: 80
Document Path: /
Document Length: 4970 bytes
Concurrency Level: 10
Time taken for tests: 18.62123 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 5163000 bytes
HTML transferred: 4970000 bytes
Requests per second: 55.36 [#/sec] (mean)
Time per request: 180.621 [ms] (mean)
Time per request: 18.062 [ms] (mean, across all concurrent requests)
Transfer rate: 279.09 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 7
Processing: 0 207 25.0 210 420
Waiting: 0 207 25.0 209 420
Total: 0 207 25.0 210 420
Percentage of the requests served within a certain time (ms)
50% 210
66% 214
75% 215
80% 217
90% 220
95% 223
98% 227
99% 230
100% 420 (longest request)
Удаленный без тюнинга:
ab -c 10 -n 1000 http://test1.ru:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking test1.ru (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx
Server Hostname: test1.ru
Server Port: 80
Document Path: /
Document Length: 4915 bytes
Concurrency Level: 10
Time taken for tests: 22.608 seconds
Complete requests: 1000
Failed requests: 6
(Connect: 0, Receive: 0, Length: 6, Exceptions: 0)
Write errors: 0
Non-2xx responses: 6
Total transferred: 5081774 bytes
HTML transferred: 4888744 bytes
Requests per second: 44.23 [#/sec] (mean)
Time per request: 226.083 [ms] (mean)
Time per request: 22.608 [ms] (mean, across all concurrent requests)
Transfer rate: 219.51 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 3 0.1 3 3
Processing: 27 223 385.7 182 8266
Waiting: 27 223 385.7 182 8265
Total: 30 226 385.7 184 8268
Percentage of the requests served within a certain time (ms)
50% 184
66% 200
75% 213
80% 222
90% 244
95% 255
98% 275
99% 2110
100% 8268 (longest request)
Удаленный с тюнингом:
ab -c 10 -n 1000 http://test1.ru:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking test1.ru (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: nginx
Server Hostname: test1.ru
Server Port: 80
Document Path: /
Document Length: 4915 bytes
Concurrency Level: 10
Time taken for tests: 21.550 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 5108000 bytes
HTML transferred: 4915000 bytes
Requests per second: 46.40 [#/sec] (mean)
Time per request: 215.504 [ms] (mean)
Time per request: 21.550 [ms] (mean, across all concurrent requests)
Transfer rate: 231.47 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 3 0.1 3 3
Processing: 109 212 33.9 213 291
Waiting: 109 212 33.9 212 290
Total: 112 215 33.9 215 293
Percentage of the requests served within a certain time (ms)
50% 215
66% 236
75% 246
80% 250
90% 259
95% 266
98% 273
99% 277
100% 293 (longest request)
Thursday, 28 January 2010
SSD захватывает мир
http://images.anandtech.com/graphs/ssdfortheenterprise_011909095250/18635.png
и
http://images.anandtech.com/reviews/storage/Intel/34nmSSD/Review/used-4kb-read-mbs.png
One X25-E is 66% faster than eight (!) 15000RPM SAS drives.
(с) http://it.anandtech.com/IT/showdoc.aspx?i=3532&p=11&cp=7 и http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=22
и
http://images.anandtech.com/reviews/storage/Intel/34nmSSD/Review/used-4kb-read-mbs.png
One X25-E is 66% faster than eight (!) 15000RPM SAS drives.
(с) http://it.anandtech.com/IT/showdoc.aspx?i=3532&p=11&cp=7 и http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=22
Postfix + noexec файловые система на /tmp
В итоге получаем такой облом:
Preconfiguring packages ...
Can't exec "/tmp/postfix.config.49981": Permission denied at /usr/share/perl/5.10/IPC/Open3.pm line 168.
open2: exec of /tmp/postfix.config.49981 configure 2.5.5-1.1 failed at /usr/share/perl5/Debconf/ConfModule.pm line 59
atop - маст хав для любого админа
Крайне рекомендую! Тулза показывает даже утилизацию канала и сколько данных было считано / записано процессов за время работы.
Как ориентироваться на http://git.kernel.org/?
На веб-интерфейсе к GIT репозиторию ядра http://git.kernel.org/ есть туева куча всяких ссылок. Какие же нам нужны? Во-первых, для всех уже выпущенных стабильных веток есть ссылки:
Чуть более сложно с поиском "текущей", то есть разрабатываемой в данный момент версии ядра. А она вот тут, как я понимаю, это ветка самого Линуса Торвальдса:
Ну вот, теперь можете серфить по просторам патчей ядра :)
...
linux/kernel/git/stable/linux-2.6.30.y.git 2.6.30-stable tree
linux/kernel/git/stable/linux-2.6.31.y.git 2.6.31-stable tree
linux/kernel/git/stable/linux-2.6.32.y.git 2.6.32-stable tree
Чуть более сложно с поиском "текущей", то есть разрабатываемой в данный момент версии ядра. А она вот тут, как я понимаю, это ветка самого Линуса Торвальдса:
linux/kernel/git/torvalds/linux-2.6.git Linus' kernel tree
Ну вот, теперь можете серфить по просторам патчей ядра :)
Wednesday, 27 January 2010
Сборка модуля Nginx Upload Progress для Debian
Офсайт патча: http://github.com/masterzen/nginx-upload-progress-module
Ставим все необходимое для сборки:
Ставим зависимости:
Открываем файл управления сборкой:
Ищем строку:
К ней добавляем:
Пересобираем:
Теперь поднимаемся на уровень выше и ставим:
Убеждаемся, что все встало:
Теперь блокируем апдейт Nginx, чтобы его не апнуло при следующем апдейте:
По мотивам: http://devblog.imedo.de/2008/05/26/building-a-nginx-debian-package-with-fair-proxy-module/
Ставим все необходимое для сборки:
apt-get install -y dpkg-dev devscripts build-essential fakeroot
Ставим зависимости:
apt-get build-dep nginx
cd /usr/src
apt-get source nginx
cd nginx-0.6.32
mkdir ngx_http_uploadprogress_module
cd ngx_http_uploadprogress_module
wget http://github.com/masterzen/nginx-upload-progress-module/raw/2bf172dac4373537927a3835d2da5b6080f6d336/ngx_http_uploadprogress_module.c
wget http://github.com/masterzen/nginx-upload-progress-module/raw/2bf172dac4373537927a3835d2da5b6080f6d336/config
cd ..
Открываем файл управления сборкой:
vi debian/rules
Ищем строку:
--with-http_ssl_module --with-http_dav_module
К ней добавляем:
--add-module=ngx_http_uploadprogress_module
Пересобираем:
debuild -us -uc # -us unsigned source, -uc unsigned changes
Теперь поднимаемся на уровень выше и ставим:
cd ..
dpkg -i nginx_0.6.32-3+lenny3_i386.deb
Убеждаемся, что все встало:
nginx -V 2>&1| grep --color uploadprogress
Теперь блокируем апдейт Nginx, чтобы его не апнуло при следующем апдейте:
echo "nginx hold" | dpkg --set-selections
По мотивам: http://devblog.imedo.de/2008/05/26/building-a-nginx-debian-package-with-fair-proxy-module/
Принимает ли PHP на Debian php.ini в текущей папке?
Принимает! А вот у Центоса в этом баг.
А вот тест:
И в итоге должно остаться только 4 разницы - различные пути к пхп ини, статус регистер глобалс, селф (хз, что это) и время исполнения запрос.
А вот тест:
cd /root
rm php.ini
echo "<?PHP phpinfo(); ?>" > test.php
php-cgi test.php > standard.log
echo "register_globals=on" > php.ini
php-cgi test.php > hacked.log
diff -u hacked.log standard.log
И в итоге должно остаться только 4 разницы - различные пути к пхп ини, статус регистер глобалс, селф (хз, что это) и время исполнения запрос.
Отличия symlink от hardlink
Мягкая ссылка (или символьная ссылка, или symlink) полностью отличается от жесткой ссылки: она является маленьким специальным файлом, который содержит путь к файлу. Таким образом, мягкая ссылка может указывать на файлы, которые находятся на других файловых системах (например, смонтированных по NFS с другой машины) и не нуждается в наличии того файла, на который она указывает. Когда происходит попытка доступа (с помощью системных вызовов open(2)
(c) http://www.opennet.ru/man.shtml?topic=ln&category=1
История в стиле fine
Крайне рекомендую к прочтению!
http://intaria.livejournal.com/66614.html
http://intaria.livejournal.com/66334.html
http://intaria.livejournal.com/66614.html
http://intaria.livejournal.com/66334.html
Monday, 25 January 2010
Включить отладочный лог Nginx
Заменяем:
На:
Ну и рестартим Nginx.
error_log /var/log/nginx/error.log;
На:
error_log /var/log/nginx/error.log debug;
Ну и рестартим Nginx.
Сколько памяти потребляет mod_php?
Простаивающий Apache c mod_php:
И без:
К слову - если переключаете PHP на FastCGI, то не забывайте отключить модуль Апача.
Под нагрузкой от ab -c 10 -n 1000 http://test1.ru:80/ получаем следующие данные: без модуля PHP 434076k free, с ним: 413046k. Так что прирост, конечно, есть. Но то, что модуль PHP при своем огромном весе шарится между детями Апача сводит весь профит на нет.
9854 root 40 0 361M 18616 9896 S 0.0 0.9 0:00.14 /usr/sbin/apache2 -k start
9855 www-data 40 0 148M 3016 476 S 0.0 0.1 0:00.01 /usr/sbin/apache2 -k start
9857 www-data 40 0 361M 11012 2172 S 0.0 0.5 0:00.00 /usr/sbin/apache2 -k start
9858 www-data 40 0 361M 11024 2184 S 0.0 0.5 0:00.00 /usr/sbin/apache2 -k start
9859 www-data 40 0 361M 10968 2136 S 0.0 0.5 0:00.00 /usr/sbin/apache2 -k start
9860 www-data 40 0 361M 9408 676 S 0.0 0.5 0:00.00 /usr/sbin/apache2 -k start
9861 www-data 40 0 361M 9404 672 S 0.0 0.5 0:00.00 /usr/sbin/apache2 -k start
И без:
10090 root 40 0 135M 4388 2228 S 0.0 0.2 0:00.06 /usr/sbin/apache2 -k start
10092 www-data 40 0 135M 2600 476 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
10093 www-data 40 0 135M 2836 656 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
10094 www-data 40 0 135M 2832 652 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
10095 www-data 40 0 135M 2832 652 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
10096 www-data 40 0 135M 2832 652 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
10097 www-data 40 0 135M 2832 652 S 0.0 0.1 0:00.00 /usr/sbin/apache2 -k start
К слову - если переключаете PHP на FastCGI, то не забывайте отключить модуль Апача.
Под нагрузкой от ab -c 10 -n 1000 http://test1.ru:80/ получаем следующие данные: без модуля PHP 434076k free, с ним: 413046k. Так что прирост, конечно, есть. Но то, что модуль PHP при своем огромном весе шарится между детями Апача сводит весь профит на нет.
Юбилей однако!
Offending key in /Users/nrg/.ssh/known_hosts:500:)
Установка Nagios из исходников
Под Debian 5:
http://phpsuxx.blogspot.com/2010/01/nagios-32-debian-5-centreon.html
Под CentOS 5:
http://phpsuxx.blogspot.com/2010/01/nagios-32-centos-5.html
http://phpsuxx.blogspot.com/2010/01/nagios-32-debian-5-centreon.html
Под CentOS 5:
http://phpsuxx.blogspot.com/2010/01/nagios-32-centos-5.html
Установка Centreon 2.1.4: установка ядра
Исходный Мануал http://en.doc.centreon.com/Setup:Centos/Fedora/RHEL
Указываем путь к бинарикам Нагиоса:
Стягиваем дистрибутив:
А далее адова куча вопросов:
Принимаем лицензию:
Выбираем все кроме Snmp Traps:
Далее указываем пути. Но разработчики КРАЙНЕ не рекомендуют их менять, Поменяете - огребете проблем, я предупредил.
Далее еще блок вопросов:
Теперь ждем, пока апгрейднутся все PEAR модули.
Потом еще отвечаем на кучу вопросов, на котороые просто тыкаем Энтер:
Далее идем по адресу: http://xx.xx.xx.xx/centreon и ставим по принципу далее-далее-далее.
Ну это пипец, господа, я задолбался.
Указываем путь к бинарикам Нагиоса:
export PATH="$PATH:/opt/nagios/bin/"
Стягиваем дистрибутив:
cd /usr/src
wget http://download.centreon.com/index.php?id=124
tar -xf centreon-2.1.4.tar.gz
cd centreon-2.1.4
./install.sh -i
А далее адова куча вопросов:
Принимаем лицензию:
Do you accept GPL license ?
[y/n], default to [n]:
> y
Выбираем все кроме Snmp Traps:
------------------------------------------------------------------------
Please choose what you want to install
------------------------------------------------------------------------
Do you want to install : Centreon Web Front
[y/n], default to [n]:
> y
Do you want to install : Centreon CentCore
[y/n], default to [n]:
> y
Do you want to install : Centreon Nagios Plugins
[y/n], default to [n]:
> y
Do you want to install : Centreon Snmp Traps process
[y/n], default to [n]:
> n
Далее указываем пути. Но разработчики КРАЙНЕ не рекомендуют их менять, Поменяете - огребете проблем, я предупредил.
------------------------------------------------------------------------
Start CentWeb Installation
------------------------------------------------------------------------
Where is your Centreon directory?
default to [/usr/local/centreon]
>
Path /usr/local/centreon OK
Where is your Centreon log directory
default to [/usr/local/centreon/log]
>
Path /usr/local/centreon/log OK
Where is your Centreon etc directory
default to [/etc/centreon]
>
Path /etc/centreon OK
Where is your Centreon generation_files directory?
default to [/usr/local/centreon]
>
Path /usr/local/centreon OK
Where is your Centreon variable library directory?
default to [/var/lib/centreon]
>
Path /var/lib/centreon OK
Where is your CentPlugins Traps binary
default to [/usr/local/centreon/bin]
>
Path /usr/local/centreon/bin OK
Where is the RRD perl module installed [RRDs.pm]
default to [/usr/lib/perl5/RRDs.pm]
>
Path /usr/lib/perl5 OK
/usr/bin/rrdtool OK
/usr/bin/mail OK
Where is PEAR [PEAR.php]
default to [/usr/share/php/PEAR.php]
>
Path /usr/share/php OK
Where is installed Nagios ?
default to [/usr/local/nagios]
> /opt/nagios
Path /opt/nagios OK
Where is your nagios config directory
default to [/usr/local/nagios/etc]
> /opt/nagios/etc
Path /opt/nagios/etc OK
Where is your Nagios var directory ?
default to [/usr/local/nagios/var]
> /opt/nagios/var
Path /opt/nagios/var OK
Where is your Nagios plugins (libexec) directory ?
default to [/usr/local/nagios/libexec]
> /opt/nagios_plugins
Path /opt/nagios_plugins OK
/opt/nagios/bin//nagios OK
Where is your Nagios image directory ?
default to [/usr/local/nagios/share/images/logos]
> /opt/nagios/share/images/logos
Path /opt/nagios/share/images/logos OK
/opt/nagios/bin//nagiostats OK
p1_file : /opt/nagios/bin/p1.pl OK
/usr/bin/php OK
/usr/bin/perl OK
Finding Apache group : www-data
Finding Apache user : www-data
Finding Nagios user : nagios
Finding Nagios group : nagios
/opt/nagios/bin//ndomod.o OK
Далее еще блок вопросов:
------------------------------------------------------------------------
Configure Sudo
------------------------------------------------------------------------
Where is sudo configuration file
default to [/etc/sudoers]
>
/etc/sudoers OK
Nagios init script OK
Your sudo is not configured
Do you want me to configure your sudo ? (WARNING)
[y/n], default to [n]:
> y
Configuring Sudo OK
------------------------------------------------------------------------
Configure Apache server
------------------------------------------------------------------------
Finding Apache Centreon configuration file
'/etc/apache2/conf.d/centreon.conf' : OK
Do you want to update Centreon Apache sub configuration file ?
[y/n], default to [n]:
> y
Create '/etc/apache2/conf.d/centreon.conf' OK
Configuring Apache OK
Do you want to reload your Apache ?
[y/n], default to [n]:
> y
Reloading Apache service OK
Preparing Centreon temporary files
Change right on /usr/local/centreon/log OK
Change right on /etc/centreon OK
Change right on /opt/nagios/share/images/logos OK
Install nagios documentation FAIL
Change macros for insertBaseConf.sql OK
Change macros for php files
Change macros for php files OK
Change right on /opt/nagios/etc OK
Copy CentWeb in system directory
Install CentWeb (web front of centreon) OK
Install libraries FAIL
Copying libinstall FAIL
Change macros for centreon.cron OK
Install Centreon cron.d file OK
Change macros for archiveDayLog OK
Change macros for centAcl.php OK
Install cron directory FAIL
------------------------------------------------------------------------
Pear Modules
------------------------------------------------------------------------
Check PEAR modules
PEAR 1.4.9 1.7.1 OK
DB 1.7.6 1.7.13 OK
DB_DataObject 1.8.4 1.9.3 OK
DB_DataObject_FormBuilder 1.0.0RC4 1.0.0 OK
MDB2 2.0.0 2.4.1 OK
Date 1.4.6 1.4.7 OK
HTML_Common 1.2.2 1.2.5 OK
HTML_QuickForm 3.2.5 3.2.11 OK
HTML_QuickForm_advmultiselect 1.1.0 1.5.1 OK
HTML_Table 1.6.1 1.8.2 OK
Archive_Tar 1.1 1.3.2 OK
Auth_SASL 1.0.1 1.0.3 OK
Console_Getopt 1.2 1.2.3 OK
Net_SMTP 1.2.8 1.4.1 OK
Net_Socket 1.0.1 1.0.9 OK
Net_Traceroute 0.21 0.21.2 OK
Net_Ping 2.4.1 2.4.5 OK
Validate 0.6.2 0.8.3 OK
XML_RPC 1.4.5 1.5.3 OK
SOAP 0.10.1 0.12.0 OK
Log 1.9.11 1.12.0 OK
All PEAR modules OK
Теперь ждем, пока апгрейднутся все PEAR модули.
Потом еще отвечаем на кучу вопросов, на котороые просто тыкаем Энтер:
------------------------------------------------------------------------
Centreon Post Install
------------------------------------------------------------------------
Create /usr/local/centreon/www/install/install.conf.php OK
Create /etc/centreon/instCentWeb.conf OK
------------------------------------------------------------------------
Start CentStorage Installation
------------------------------------------------------------------------
Where is your Centreon Run Dir directory?
default to [/var/run/centreon]
>
Path /var/run/centreon OK
Where is your CentStorage binary directory
default to [/usr/local/centreon/bin]
>
Path /usr/local/centreon/bin OK
Where is your CentStorage RRD directory
default to [/var/lib/centreon]
>
Path /var/lib/centreon OK
Finding Nagios group : nagios
Finding Nagios user : nagios
Preparing Centreon temporary files
/tmp/centreon-setup exists, it will be moved...
install www/install/createTablesCentstorage.sql OK
CentStorage status Directory already exists PASSED
CentStorage metrics Directory already exists PASSED
Change macros for centstorage binary OK
Install CentStorage binary OK
Install library for centstorage FAIL
Change right : /var/run/centreon OK
Change macros for centstorage init script OK
Do you want me to install CentStorage init script ?
[y/n], default to [n]:
>
CentStorage init script not installed, please use :
/usr/local/centreon/examples/centstorage.init.d PASSED
Change macros for logAnalyser OK
Install logAnalyser OK
Change macros for nagiosPerfTrace OK
Install nagiosPerfTrace OK
Change macros for purgeLogs OK
Install purgeLogs OK
Change macros for purgeCentstorage OK
Install purgeCentstorage OK
Change macros for centreonPurge.sh OK
Install centreonPurge.sh OK
Change macros for centstorage.cron OK
Install CentStorage cron OK
Create /etc/centreon/instCentStorage.conf OK
------------------------------------------------------------------------
Start CentCore Installation
------------------------------------------------------------------------
Where is your CentCore binary directory
default to [/usr/local/centreon/bin]
>
Path /usr/local/centreon/bin OK
/usr/bin/ssh OK
/usr/bin/scp OK
Finding Nagios group : nagios
Finding Nagios user : nagios
Preparing Centreon temporary files
/tmp/centreon-setup exists, it will be moved...
Change CentCore Macro OK
Copy CentCore in binary directory OK
Change right : /var/run/centreon OK
Change right : /var/lib/centreon OK
Replace CentCore init script Macro OK
Do you want me to install CentCore init script ?
[y/n], default to [n]:
>
CentCore init script not installed, please use :
/usr/local/centreon/examples/centcore.init.d PASSED
Create /etc/centreon/instCentCore.conf OK
------------------------------------------------------------------------
Start CentPlugins Installation
------------------------------------------------------------------------
Where is your CentPlugins lib directory
default to [/var/lib/centreon/centplugins]
>
Path /var/lib/centreon/centplugins OK
Finding Nagios user : nagios
Finding Nagios group : nagios
Preparing Centreon temporary files
/tmp/centreon-setup exists, it will be moved...
Change macros for CentPlugins OK
Installing the plugins OK
Change right on centreon.conf OK
CentPlugins is installed
Create /etc/centreon/instCentPlugins.conf OK
###############################################################################
# #
# Go to the URL : http://your-server/centreon/ #
# to finish the setup #
# #
# Report bugs at http://forge.centreon.com #
# #
# Thanks for using Centreon. #
# ----------------------- #
# Contact : infos@centreon.com #
# http://www.centreon.com #
# #
###############################################################################
Далее идем по адресу: http://xx.xx.xx.xx/centreon и ставим по принципу далее-далее-далее.
Ну это пипец, господа, я задолбался.
Установка Centreon: установка зависимостей
Ставим маилер и вспомогательный софт:
Все необходимое для сборки:
Пхп с зависимостями:
MySQL:
RRD:
Perl & co:
GD:
Продолжение установки в следующей статье.
источник: http://en.doc.centreon.com/Setup:Prerequisite/Debian/Ubuntu
apt-get install -y --force-yes sudo tofrodos mailx lsb-release
Все необходимое для сборки:
apt-get install -y --force-yes build-essential
Пхп с зависимостями:
apt-get install -y --force-yes php5 php5-mysql php-pear php5-ldap php5-snmp php5-gd
MySQL:
apt-get install -y --force-yes mysql-server-5.0 libmysqlclient15-dev
RRD:
apt-get install -y --force-yes rrdtool librrds-perl
Perl & co:
apt-get install -y --force-yes libconfig-inifiles-perl libcrypt-des-perl libdigest-hmac-perl libdigest-sha1-perl libgd-gd2-perl
GD:
apt-get install -y --force-yes libgd2-xpm libgd2-xpm-dev libpng12-dev
Продолжение установки в следующей статье.
источник: http://en.doc.centreon.com/Setup:Prerequisite/Debian/Ubuntu
Как на Debian поставить все необходимое для сборки софта из сорцов?
Для этого есть спец-пакет, который все ставит за 1 раз:
apt-get install -y --force-yes build-essential
Сборка Nagios 3.2 на Debian 5 из исходников
Установка Nagios
Ставим Апача:
Создаем юзера для Nagios:
Создаем группу (это необходимо, чтобы разрешить от имени Апача вызывать внешние команды):
Добавляем юзера Nagios а в это группу:
В нее же добавляем Апача:
Ставим зависимости:
Добавляем в автозапуск:
Запускаем:
Установка Nagios плагинов
Стягиваем сорцы:
Ставим зависимости:
Собираем:
Ставим NDO, он необходим для связи Nagios с MySQL.
Ставим зависимости:
Собираем:
Также по-хорошему, надо добавить этот демон (ndodb) в автозапуск, но чуть позже.
источник: http://en.doc.centreon.com/Setup:CompileNagiosPlugins и http://en.doc.centreon.com/Setup:CompileNagios и http://en.doc.centreon.com/Setup:ndoutils
Ставим Апача:
apt-get install apache2 -y --force-yes
Создаем юзера для Nagios:
useradd -m nagios
Создаем группу (это необходимо, чтобы разрешить от имени Апача вызывать внешние команды):
groupadd nagcmd
Добавляем юзера Nagios а в это группу:
usermod -G nagios,nagcmd nagios
В нее же добавляем Апача:
usermod -G nagios,nagcmd www-data
cd /usr/src
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.0.tar.gz
tar -xf nagios-3.2.0.tar.gz
cd nagios-3.2.0
Ставим зависимости:
apt-get update
apt-get install -y --force-yes make gcc libpng12-dev libjpeg62-dev libgd2-xpm-dev
./configure --prefix=/opt/nagios --with-command-group=nagcmd --enable-nanosleep --enable-event-broker
make all
make install
make install-init
make install-commandmode
make install-config
Добавляем в автозапуск:
update-rc.d nagios defaults
Запускаем:
/etc/init.d/nagios start
Установка Nagios плагинов
Стягиваем сорцы:
cd /usr/src
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.14.tar.gz
tar -xf nagios-plugins-1.4.14.tar.gz
cd nagios-plugins-1.4.14
Ставим зависимости:
apt-get install -y --force-yes fping libnet-snmp-perl libssl-dev dnsutils
Собираем:
./configure --prefix=/opt/nagios_plugins --with-nagios-user=nagios --with-nagios-group=nagios --with-openssl=/usr/bin/openssl
make
make install
Ставим NDO, он необходим для связи Nagios с MySQL.
Ставим зависимости:
apt-get install -y --force-yes libmysqlclient15-dev
cd /usr/src
wget http://prdownloads.sourceforge.net/sourceforge/nagios/ndoutils-1.4b9.tar.gz
tar -xf ndoutils-1.4b9.tar.gz
cd ndoutils-1.4b9
Собираем:
./configure --prefix=/opt/nagios --enable-mysql --disable-pgsql --with-ndo2db-user=nagios --with-ndo2db-group=nagios
make
make install
Также по-хорошему, надо добавить этот демон (ndodb) в автозапуск, но чуть позже.
источник: http://en.doc.centreon.com/Setup:CompileNagiosPlugins и http://en.doc.centreon.com/Setup:CompileNagios и http://en.doc.centreon.com/Setup:ndoutils
Centreon - Nagios с удобным интерфейсом, конфигуратором и установкой!
Т.к. приведение Nagios в юзабельный вид задача не из простых, я решил найти альтернативу. И нашел - Centreon 2.1.4. А чем, собственно, он лучше, чем Nagios ? Вот этим: http://www.centreon.com/Centreon/product-overview.html
Но, вообще говоря, сравнивать их некорректно, т.к. Centreon построен на базе ядра Nagios. Так что если это сравнивать в более понятных сущностях, то Nagios - это двигатель Porsche, а Centreon - это сам Porsche :)
Так что это не более чем грамотно настроенный и с красивой мордочкой монстр Nagios.
Основные преимущества:
0. Красивый, удобный интерфейс, а не тот ужас, который у Nagios. Скриншоты
1. Управление через веб-интерфейс (в Nagios для этого надо редактировать конфиги, что suxx)
2. Служебные данные хранятся в MySQL, в то время как даныне мониторинга хранятся в очень оптимальном для этого формате - RRD.
3. Удобная настройка уведомлений на почту / sms.
Если кто уже рвется ставить, то вот ссылки на инсталляцию для Debian и CentOS: http://en.doc.centreon.com/Setup
Update: вопщем, радость была недолгой, очень неудобный и перегруженный интерфейс + жуткая установка.
Но, вообще говоря, сравнивать их некорректно, т.к. Centreon построен на базе ядра Nagios. Так что если это сравнивать в более понятных сущностях, то Nagios - это двигатель Porsche, а Centreon - это сам Porsche :)
Так что это не более чем грамотно настроенный и с красивой мордочкой монстр Nagios.
Основные преимущества:
0. Красивый, удобный интерфейс, а не тот ужас, который у Nagios. Скриншоты
1. Управление через веб-интерфейс (в Nagios для этого надо редактировать конфиги, что suxx)
2. Служебные данные хранятся в MySQL, в то время как даныне мониторинга хранятся в очень оптимальном для этого формате - RRD.
3. Удобная настройка уведомлений на почту / sms.
Если кто уже рвется ставить, то вот ссылки на инсталляцию для Debian и CentOS: http://en.doc.centreon.com/Setup
Update: вопщем, радость была недолгой, очень неудобный и перегруженный интерфейс + жуткая установка.
Установка Nagios 3.2 на CentOS 5 из исходников
В репозитории Epel Nagios слишком уж старый:
Поэтому поставим его из исходников:
Создаем юзера для Nagios:
Ставим зависимости:
Собираем:
Добавляем его в автозапуск:
Запускаем:
yum info nagios | grep Version
Version : 2.12
Поэтому поставим его из исходников:
cd /usr/src
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.0.tar.gz
tar -xf nagios-3.2.0.tar.gz
cd nagios-3.2.0
Создаем юзера для Nagios:
useradd nagios
Ставим зависимости:
yum -y install gd-devel png-devel jpeg-devel
Собираем:
./configure --prefix=/opt/nagios32
make all
make install # ставим саму программу
make install-init # ставим init скрипт
make install-config # ставим конфиги Nagios
make install-webconf # ставим конфиг веб-интерфейса
Добавляем его в автозапуск:
chkconfig --add nagios
chkconfig nagios on
Запускаем:
/etc/init.d/nagios start
Установка сервера HylaFAX 6.0.4 на Debian 5 Lenny
Офсайт: http://www.hylafax.org/content/Main_Page
Ставим зависимости:
Добавляем в автозапуск:
Запускаем конфигуратор:
При этом необходимо будет ответить на кучу вопросов и указать порт модема, обычно это ttyS0. Также конфигуратор у меня тупил и пускал вопросы повторно, поэтому пришлось его прибить по CTRL+C, но на работу программы это не повлияло.
Запускаем:
Убеждаемся, что все запустилось:
На случай проблем свои логи он хранит вот здесь:
cd /usr/src
wget ftp://ftp.hylafax.org/source/hylafax-6.0.4.tar.gz
tar -xf hylafax-6.0.4.tar.gz
cd hylafax-6.0.4
Ставим зависимости:
apt-get install -y --force-yes gcc g++ make libtiff4-dev libtiff-tools ghostscript
./configure
make
make install
Добавляем в автозапуск:
update-rc.d hylafax defaults
Запускаем конфигуратор:
faxsetup
При этом необходимо будет ответить на кучу вопросов и указать порт модема, обычно это ttyS0. Также конфигуратор у меня тупил и пускал вопросы повторно, поэтому пришлось его прибить по CTRL+C, но на работу программы это не повлияло.
Запускаем:
/etc/init.d/hylafax start
Убеждаемся, что все запустилось:
ps aux | grep hy
uucp 31205 0.0 0.1 31880 1132 ? Ss 09:50 0:00 /usr/local/sbin/hfaxd -i hylafax
root 31207 0.0 0.0 5160 772 pts/0 R+ 09:50 0:00 grep hy
На случай проблем свои логи он хранит вот здесь:
tail -f /var/log/syslog
iptables, забанить подсеть
iptables -I INPUT -s xx.xx.xx.xx/24 -j DROP
4 самых красивых веб-интерфейса к Nagios
1. http://www.centreon.com/ - протестировал, слишком сложная установка и перегруженный интерфейс.
2. http://www.lilacplatform.com/
3. http://www.nagiosql.org/demo.html
4. http://opsview.org
Via http://www.ducea.com/2008/01/16/10-nagios-web-frontends/
2. http://www.lilacplatform.com/
3. http://www.nagiosql.org/demo.html
4. http://opsview.org
Via http://www.ducea.com/2008/01/16/10-nagios-web-frontends/
Определение DoS/DDoS атак на сервер
Часто меня спрашивают, как узнать - идет ли DoS атака на сервер? С одной стороны это очевидно, но далеко не для всех и далеко не всегда. В этом посте постараюсь собирать все формальные признаки атак, по которым их можно легко определить.
Во-первых, посомтрим число процессов Апача:
Либо в случае ОС CentOS5/RHEL:
Если их более 20-30, то это уже повод для беспокойства.
Далее обязательно просмотреть глобальные логи Апача на предмет наличия аномалий (например, запросов без указания вихоста):
И для CentOS:
Далее, стоит просмотреть логи всех сайтов (например, в случае использования панели ISPManager они лежат в папке /var/www/httpd-logs) и обратить особое внимание на самые большие из них.
Если "большой" лог найден, то его стоить проанализировать на предмет аномалий следующим образом:
Эта команда укажет число запросов до сайта с уникальных айпи, вывод ее будет в виде:
Таким образом, если какой-то IP / блок айпи заваливает сайт запросами, это будет видно по резко уходящим в верх значениям запросов для IP злоумышленников.
Если же используется Nginx, то также обязательно просматривать логи:
Продолжение следует :)
Во-первых, посомтрим число процессов Апача:
ps aux | grep apache | wc -l
Либо в случае ОС CentOS5/RHEL:
ps aux | grep httpd | wc -l
Если их более 20-30, то это уже повод для беспокойства.
Далее обязательно просмотреть глобальные логи Апача на предмет наличия аномалий (например, запросов без указания вихоста):
/var/log/apache2/error.log
/var/log/apache2/access.log
И для CentOS:
/var/log/httpd/error.log
/var/log/httpd/access.log
Далее, стоит просмотреть логи всех сайтов (например, в случае использования панели ISPManager они лежат в папке /var/www/httpd-logs) и обратить особое внимание на самые большие из них.
Если "большой" лог найден, то его стоить проанализировать на предмет аномалий следующим образом:
cat log_type.log | awk '{print $1}' | sort | uniq -c
Эта команда укажет число запросов до сайта с уникальных айпи, вывод ее будет в виде:
14 95.67.xx.xx
21 95.68.xx.xx
25 95.68.xx.xx
15 95.68.xx.xx
15 95.68.xx.xx
1 95.69.xx.xx
15 95.70.xx.xx
1 95.70.xx.xx
21 95.70.xx.xx
24 95.70.xx.xx
22 95.70.xx.xx
15 95.70.xx.xx
17 95.70.xx.xx
1 95.70.xx.xx
Таким образом, если какой-то IP / блок айпи заваливает сайт запросами, это будет видно по резко уходящим в верх значениям запросов для IP злоумышленников.
Если же используется Nginx, то также обязательно просматривать логи:
/var/log/nginx/error.log
/var/log/nginx/access.log
Продолжение следует :)
Sunday, 24 January 2010
Установка aptitude на Debian 5 Lenny
apt-get update && apt-get install aptitude -y --force-yes
Защита от исходящего спама на Postfix / Debian
Чтобы запретить всем, кроме пользователя Postfix и рута соединяться с серверами на 25й порт необходимо внести в фаерволл следующие правила:
Теперь протестируем:
А все остальные пользователи получают облом:
При этом почтовик также работает отлично:
iptables -A OUTPUT -o lo -j ACCEPT # разрешаем соединения с loopback
iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner postfix -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --gid-owner root -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 25 -j DROP
Теперь протестируем:
# id
uid=0(root) gid=0(root) groups=0(root)
# telnet smtp.mail.ru 25
Trying 94.100.177.1...
Connected to smtp.mail.ru.
Escape character is '^]'.
220 mail.ru ESMTP Sun, 24 Jan 2010 19:15:27 +0300
А все остальные пользователи получают облом:
$ id
uid=1000(nrg) gid=1000(nrg) groups=1000(nrg)
$ telnet smtp.mail.ru 25
Trying 94.100.177.1...
При этом почтовик также работает отлично:
echo test | mail -s test odintsov@test.ru
sftp в chrooted ssh в Debian 6 Wheezy
Открываем конфиг:
Ищем там:
Заменяем на:
То есть иными словами, мы не можем использовать внешнюю программу, т.к. ее не будет у нас в чруте и поэтому переключаемся на встроенный механизм.
Создаем юзера:
Меняем владельца домашней папки юзера - это обязательное требования для чрута в нее (иначе получите: sshd[6341]: fatal: bad ownership or modes for chroot directory "/home/nrg"):
Также добавляем юзера, которого будем чрутить:
Перезапускаем демона SSH:
Подключаемся:
Вот и все, пользователь не имеет доступа никуда, кроме своей домашней папки :)
Подробности можно прочесть в мане:
Источник: http://undeadly.org/cgi?action=article&sid=20080220110039 и http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny и http://blog.antage.name/posts/sftp-chroot-%D0%B2-%D0%B4%D0%BE%D0%BC%D0%B0%D1%88%D0%BD%D1%8E%D1%8E-%D0%BF%D0%B0%D0%BF%D0%BA%D1%83.html
vi /etc/ssh/sshd_config
Ищем там:
Subsystem sftp /usr/lib/openssh/sftp-server
Заменяем на:
Subsystem sftp internal-sftp
То есть иными словами, мы не можем использовать внешнюю программу, т.к. ее не будет у нас в чруте и поэтому переключаемся на встроенный механизм.
Создаем юзера:
useradd nrg -m
passwd nrg
Меняем владельца домашней папки юзера - это обязательное требования для чрута в нее (иначе получите: sshd[6341]: fatal: bad ownership or modes for chroot directory "/home/nrg"):
chown root.root /home/nrg/
Также добавляем юзера, которого будем чрутить:
Match user nrg
ForceCommand internal-sftp
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
Перезапускаем демона SSH:
/etc/init.d/ssh restart
Подключаемся:
sftp -oPort=22 nrg@v1.test.ru
Connecting to v1.test.ru...
nrg@v1.test.ru's password:
sftp> ls /
/123123 /suxxxx
sftp>
Вот и все, пользователь не имеет доступа никуда, кроме своей домашней папки :)
Подробности можно прочесть в мане:
man 5 sshd_config
Источник: http://undeadly.org/cgi?action=article&sid=20080220110039 и http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny и http://blog.antage.name/posts/sftp-chroot-%D0%B2-%D0%B4%D0%BE%D0%BC%D0%B0%D1%88%D0%BD%D1%8E%D1%8E-%D0%BF%D0%B0%D0%BF%D0%BA%D1%83.html
Как прописать set names, если скрипт закрыт Zend?
Добавить в my.cnf в блок [mysqld] следующее:
init-connect="SET NAMES cp1251"
Puppet: просмотреть список всех подписанных сертификатов
puppetca --list all
Отключение восстановления пароля ISPManager
Открыть конфиг:
И в самый низ добавляем:
Перезапускаем панель:
(с) http://forum.ispsystem.com/ru/showthread.php?t=6838
vi /usr/local/ispmgr/etc/ispmgr.conf
И в самый низ добавляем:
FuncAccess recovery deny
Перезапускаем панель:
killall -9 -r ispmgr
(с) http://forum.ispsystem.com/ru/showthread.php?t=6838
Отличия tmpfs и ramfs
Обе эти файловые системы присутствуют во всех новых ядрах совместно и на первый взгляд выполняют схожие задачи. Но ключевое отличие у них в поведении, когда кончается оперативная память. В этом случае tmpfs использует swap, а ramfs ничего не использует и просто сообщает, что оперативка, сэр, кончилась :)
Postfix и noexec ФС
Postfix sets the execute bit to indicate that a queue file is
complete. On file systems that don't allow users to set the execute
bit on a file, Postfix will never deliver mail.
Так что с этим надо быть аккуратнее.
(c) http://archives.neohapsis.com/archives/postfix/2006-01/1916.html
Saturday, 23 January 2010
Скрипт для просмотра онлайна сервера La2
vi /opt/online.sh
#!/bin/bash
mysql -uroot -pPASSWORD -DDATABASE_NAME -e "select count(*) from characters where online = '1';"
Описание полей утилиты slabtop
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-proc-topfiles.html#s2-proc-slabinfo
А вот удобный способ запуска, чтобы посмотреть, какие кэши уже забиты: slabtop --sort u
А вот удобный способ запуска, чтобы посмотреть, какие кэши уже забиты: slabtop --sort u
Оптимизация работы ПО посредством Huge TLB fs
http://www.cyberciti.biz/tips/tag/vmhugetlb_shm_group
А вот и библиотека, чтобы заставить любой софт работать с HugeTLB без изменения кода: http://libhugetlbfs.ozlabs.org/
А вот мануал по его активации: http://www.linux-kvm.com/content/get-performance-boost-backing-your-kvm-guest-hugetlbfs
Ожидаемый прирост в скорости - около 10%. Насколько реально - не знаю.
А вот и библиотека, чтобы заставить любой софт работать с HugeTLB без изменения кода: http://libhugetlbfs.ozlabs.org/
А вот мануал по его активации: http://www.linux-kvm.com/content/get-performance-boost-backing-your-kvm-guest-hugetlbfs
Ожидаемый прирост в скорости - около 10%. Насколько реально - не знаю.
Да будет свет!
По-моему, очень зачотно: http://www.contex-condom.ru/products.php?txt_id=334&parent_id=14
Thursday, 21 January 2010
VDSManager внутренняя ошибка VDS not found
VDSManager внутренняя ошибка VDS not found
Кому нужен фикс для 64 битной версии под Linux - прошу на почту pavel.odintsov (собака) googlemail.com Для тех, кто в теме поясняю - ошибка появилась в новой версии VDSManager вышедшей 19го января, фиксица так:
Ищем ноду (ну или пишем мне почтой - вышлю файл) с предыдущей версией панели и стягиваем с нее файл /usr/local/ispmgr/lib/openvz.so
Рестартим панель:
Кому нужен фикс для 64 битной версии под Linux - прошу на почту pavel.odintsov (собака) googlemail.com Для тех, кто в теме поясняю - ошибка появилась в новой версии VDSManager вышедшей 19го января, фиксица так:
cd /usr/local/ispmgr/lib
Ищем ноду (ну или пишем мне почтой - вышлю файл) с предыдущей версией панели и стягиваем с нее файл /usr/local/ispmgr/lib/openvz.so
Рестартим панель:
killall -9 -r vdsmgr
Монти Видениус, Мускул и вопли про "Мускул RIP"
Задолбали, понятна? Не по-мужски так поступать - продать, а потом устраивать пикеты "не убивайте мускул не убивайте мускул". Не хотите чтобы убивали - так нех и продаваться было. Низко и противно.
Cлишком большой файл ibdata1 в MySQL
Этот файл используется движком InnoDB для хранения таблиц, при этом все таблицы хранятся в одном файле, что очень неудобно.
Для активации разделения баз данных по разным файлам используется следующая опция в my.cnf (добавлять в блок [mysqld]):
После этого необходим рестарт СУБД:
Все, теперь все вновь создаваемые InnoDB таблицы будут создаваться в отдельных файлах внутри папок с именами баз данных (с расширением .ibd, причем и индексы и данные лежат вместе).
источник: http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html
Для активации разделения баз данных по разным файлам используется следующая опция в my.cnf (добавлять в блок [mysqld]):
innodb_file_per_table
После этого необходим рестарт СУБД:
/etc/init.d/mysqld restart
Все, теперь все вновь создаваемые InnoDB таблицы будут создаваться в отдельных файлах внутри папок с именами баз данных (с расширением .ibd, причем и индексы и данные лежат вместе).
источник: http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html
Аналог Zend и ionCube
Вот натолкнулся на такой, полагаю, популярный на Западе продукт: http://www.sourceguardian.com/
Рекомендация размещать /tmp и /var/tmp на tmpfs от разработчиков ядра
http://www.mjmwired.net/kernel/Documentation/filesystems/tmpfs.txt
Some people (including me) find it very convenient to mount it e.g. on /tmp and /var/tmp and have a big swap partition. And now loop mounts of tmpfs files do work, so mkinitrd shipped by most distributions should succeed with a tmpfs /tmp.
Wednesday, 20 January 2010
Установка PHP как FastCGI на панели управления хостингом ISPManager, Debian 5 Lenny
В новых версиях все намного проще! Просто идете в "Возможности", выбираете там "Модуль FastCGI для веб-сервера Apache" и нажимаете на "кнопку с дисками" для установки и ожидаете, пока он поставится на панель. После этого должна появиться опция PHP как FastCGI при создании www-доменов.
Ставим:
Перезапускаем апача:
Перезапускаем панель ISPManager:
Готово, теперь в настройках www домена должна появится возможность "Php как FastCGI".
Но в последних версиях этот фикс не сработает, ибо в панели опять что-то сломали!
Открываем конфиг:
И в самый низ добавляем следующее:
Перезапускаем панель ISPManager:
И вот теперь уж точно должно появиться :)
Ставим:
apt-get install -y libapache2-mod-fcgid
Перезапускаем апача:
/etc/init.d/apache2 restart
Перезапускаем панель ISPManager:
killall -9 -r ispmgr
Готово, теперь в настройках www домена должна появится возможность "Php как FastCGI".
Но в последних версиях этот фикс не сработает, ибо в панели опять что-то сломали!
Открываем конфиг:
vi /usr/local/ispmgr/etc/ispmgr.conf
И в самый низ добавляем следующее:
Option ForcePhpFCgid
Перезапускаем панель ISPManager:
killall -9 -r ispmgr
И вот теперь уж точно должно появиться :)
Переключение ext4 журнала на writeback
Открываем fstab:
Ищем там свой рут раздел:
У меня это /dev/md2.
Т.к. вариант с указанием в fstab data=writeback не работает, Ибо баг - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529629 и https://bugzilla.redhat.com/show_bug.cgi?id=55495
Идем в обход, активируем для файловой системы дефлтную опцию монтирования:
В итоге получаем:
Перезагружаемся (mount -o remount / тут не сработает):
Убеждаемся, что наш основной раздел смонтировался в writeback (кто подскажет более правильный способ - получит плюшку):
vi /etc/fstab
Ищем там свой рут раздел:
/dev/md2 / ext3 defaults,grpquota,usrquota 0 0
У меня это /dev/md2.
Т.к. вариант с указанием в fstab data=writeback не работает, Ибо баг - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529629 и https://bugzilla.redhat.com/show_bug.cgi?id=55495
Идем в обход, активируем для файловой системы дефлтную опцию монтирования:
tune2fs -o journal_data_writeback /dev/md2
В итоге получаем:
Суть внесенных правок:
tune2fs -l /dev/md2 | grep writeback
Default mount options: journal_data_writeback
< Default mount options: journal_data_writeback user_xattr acl
---
> Default mount options: user_xattr acl
Перезагружаемся (mount -o remount / тут не сработает):
shutdown -r now
Убеждаемся, что наш основной раздел смонтировался в writeback (кто подскажет более правильный способ - получит плюшку):
dmesg | grep writeback
[ 4.095211] EXT3-fs: mounted filesystem with writeback data mode.
Беслптный CDN
Эка что бывает: http://www.coralcdn.org/
Актуальный (!!!!) ежедневно обновляемый список всех российских сетей
Прошу: http://noc.masterhost.ru/allrunet/ А вот и от Зенона: http://noc.zenon.net/nets/current
Мастерхосту и Зенону огромный респект за такую няшку!
А вот и мануал, как использовать эти правила в Nginx для защиты от слабых DDoS / DoS: http://www.opennet.ru/tips/info/1717.shtml
Мастерхосту и Зенону огромный респект за такую няшку!
А вот и мануал, как использовать эти правила в Nginx для защиты от слабых DDoS / DoS: http://www.opennet.ru/tips/info/1717.shtml
Nginx 0.7.64 + reload ( graceful ) - насколько хорошо работает?
Протестируем следующим образом.
На тестовой машине:
На машине, где запускаем ab:
В итоге имеем отличные результаты:
То есть не потеряно ни одного пакета и нету явных провалов по скорости.
Nginx при этом занимался проксированием Apache:
На тестовой машине:
while true; do /etc/init.d/nginx reload ; sleep 1; done
На машине, где запускаем ab:
ab -c 10 -n 1000 http://test1.ru:80/
В итоге имеем отличные результаты:
Server Software: nginx
Server Hostname: test1.ru
Server Port: 80
Document Path: /
Document Length: 4970 bytes
Concurrency Level: 10
Time taken for tests: 19.418320 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 5163000 bytes
HTML transferred: 4970000 bytes
Requests per second: 51.50 [#/sec] (mean)
Time per request: 194.183 [ms] (mean)
Time per request: 19.418 [ms] (mean, across all concurrent requests)
Transfer rate: 259.60 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 9
Processing: 0 220 31.0 216 311
Waiting: 0 219 31.0 216 310
Total: 0 220 31.0 216 311
Percentage of the requests served within a certain time (ms)
50% 216
66% 224
75% 229
80% 235
90% 257
95% 271
98% 279
99% 287
100% 311 (longest request)
То есть не потеряно ни одного пакета и нету явных провалов по скорости.
Nginx при этом занимался проксированием Apache:
location / {
proxy_pass http://xx.xx.xx.xx:8080;
proxy_redirect http://v1.test.ru:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
Тюнинг файловой системы Ext3 - увеличение commit
У Ext3 есть параметр commit, указывающий время, через которое происходит синхронизация данных и метаданных с жестким диском, стандартно оно равняется 5 секундам (см. исходники ядра), но в некоторых случаях его можно увеличить без особого вреда, скажем, до 10 секунд, чтобы лишний раз не дергать диски.
Вот информация на английском:
Настраиваем!
Открываем fstab:
Ищем там строку с нашей файловой системой и добавляем в нее через запятую "commit=10":
Перемонтируем файловую систему:
Все, теперь данные на диск у нас будут сбрасываться раз в 10 секунд.
Вот информация на английском:
commit=nrsec (*) Ext3 can be told to sync all its data and metadata every 'nrsec' seconds. The default value is 5 seconds. This means that if you lose your power, you will lose as much as the latest 5 seconds of work (your filesystem will not be damaged though, thanks to the journaling). This default value (or any low value) will hurt performance, but it's good for data-safety. Setting it to 0 will have the same effect as leaving it at the default (5 seconds). Setting it to very large values will improve performance.
Настраиваем!
Открываем fstab:
vi /etc/fstab
Ищем там строку с нашей файловой системой и добавляем в нее через запятую "commit=10":
/dev/md2 / ext3 defaults,commit=10,grpquota,usrquota 0 0
Перемонтируем файловую систему:
mount -o remount /
Все, теперь данные на диск у нас будут сбрасываться раз в 10 секунд.
ext3 ordered (стандартый) vs writeback (самый быстрый)
Рекомендовано к прочтению: http://lwn.net/Articles/329008/
Может ли отключение atime для файловой системы негативно сказаться на работе Postfix?
Может ли отключение atime для файловой системы негативно сказаться на работе Postfix?
Ответ: Нет
Аргументация: судя по рассылке Postfix его не использует:
И даже сам Виетс Винема (автор Postfix - http://ru.wikipedia.org/wiki/Postfix) это подтверждает:
Ответ: Нет
Аргументация: судя по рассылке Postfix его не использует:
> One suggestion which seemed rather interesting to me was mounting a
> filesystem with the noatime flag. I certainly don't use it in my general
> activities on a server but I was just wondering if anyone can tell me if
> postfix uses it?
Postfix doesn't use it.
И даже сам Виетс Винема (автор Postfix - http://ru.wikipedia.org/wiki/Postfix) это подтверждает:
Turning off atime updates means don't update the inode block when
a file is read.
I have many reasons to believe that would make zero difference,
because the inode block needs to be updated anyway after Postfix
accesses a queue file.
With each access, Postfix either creates or renames or deletes the
file, and/or it writes the queue file, and/or it sets the mtime
explicitly. All these require that the inode block be updated.
Отключение atime для ext3 разделов с интенсивным доступом
Отключение поддержки atime (время последнего доступа) позволяет увеличить производительность дисковой подсистемы.
Вот описание, как и почему стоит это делать:
Вкратце - при каждом доступе к файлу (хоть на чтение, хоть на запись) файловая система изменяет время последнего доступа к файлу (atime) на текущее и записывает его в файловую систему, что влияет не лучшим образом на производительность (теоретически, практически я ничего сказать не могу - не тестил).
Открываем конфиг:
Ищем строку с требуемой файловой системой:
И добавляем через запятую после default notatime,nodiratime чтобы получить следующее:
Перемонтируем файловую систему:
Возможные противопоказания: http://phpsuxx.blogspot.com/2010/01/atime-postfix.html
источники:
http://www.findmysoft.com/news/Disable-Atime-for-a-Faster-Running-Linux-OS/
http://en.opensuse.org/Speeding_up_Ext3
http://www.redhat.com/support/wpapers/redhat/ext3/tuning.html
Вот описание, как и почему стоит это делать:
Here is how atime works: for every instance that the operating system accesses a file, atime logs the time when that file was last accessed (writes this info onto the Linux ext3 partition). As you can imagine, all this writing takes its toll in terms of performance, which is a drag (no pun intended) considering that only mail-monitoring and defragmenting applications use atime to function properly.
Вкратце - при каждом доступе к файлу (хоть на чтение, хоть на запись) файловая система изменяет время последнего доступа к файлу (atime) на текущее и записывает его в файловую систему, что влияет не лучшим образом на производительность (теоретически, практически я ничего сказать не могу - не тестил).
Открываем конфиг:
vi /etc/fstab
Ищем строку с требуемой файловой системой:
/dev/md2 / ext3 defaults,grpquota,usrquota 0 0
И добавляем через запятую после default notatime,nodiratime чтобы получить следующее:
/dev/md2 / ext3 defaults,noatime,nodiratime,grpquota,usrquota 0 0
Перемонтируем файловую систему:
mount -o remount /
Возможные противопоказания: http://phpsuxx.blogspot.com/2010/01/atime-postfix.html
источники:
http://www.findmysoft.com/news/Disable-Atime-for-a-Faster-Running-Linux-OS/
http://en.opensuse.org/Speeding_up_Ext3
http://www.redhat.com/support/wpapers/redhat/ext3/tuning.html
Tuesday, 19 January 2010
Новинка в mod_fcgid 2.3.5 - показ статуса процессов в server-status
Display information about active processes in the server-status page. [Ryan Pan]
(c) CHANGES-FCGID
Куда пропал оф сайт mod_fcgid http://fastcgi.coremail.cn/doc.htm ?
Последнюю неделю пытаюсь зайти на http://fastcgi.coremail.cn/doc.htm, но обламываюсь :( Думал, что просто лежит. Оказывается нет:
(с) http://httpd.apache.org/mod_fcgid/
mod_fcgid was created by Ryan Pan (Pan Qingfeng, pqf or 潘庆峰) in 2004 as a new FastCGI implementation, and was granted to the ASF as an Apache HTTP Server subproject in 2009, shepherded by Chris Darroch (chrisd).
(с) http://httpd.apache.org/mod_fcgid/
'struct task_struct' has no member named 'uid' в 29+ ядрах
Фиксица поиском вызовов элементов структуры uid (->uid) и заменой их на ->cred->uid
(c) http://forums.virtualbox.org/viewtopic.php?t=12854
(c) http://forums.virtualbox.org/viewtopic.php?t=12854
Как делать патчи для ядра?
Рассматривать все будем на примере 2.6.32.4
Подготавливаем дерево исходников ядра:
Теперь производим копирование оригинального дерева в то, которое будем изменять (оно с суффиксом _patched):
Теперь вносим коррективы в файлы в папке linux-2.6.32.4_patched.
Теперь создаем патч:
Ну вот и все, теперь для последующего наложения патча необходимо перейти в корень дерева исходников и выполнить команду:
И после этого получим пропатченное дерево исходников :)
Подготавливаем дерево исходников ядра:
cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.4.tar.bz2
tar -xf linux-2.6.32.4.tar.bz2
Теперь производим копирование оригинального дерева в то, которое будем изменять (оно с суффиксом _patched):
cp -R linux-2.6.32.4 linux-2.6.32.4_patched
Теперь вносим коррективы в файлы в папке linux-2.6.32.4_patched.
Теперь создаем патч:
cd /usr/src
diff -rupN linux-2.6.32.4 linux-2.6.32.4_patched > our_patch.patch
Ну вот и все, теперь для последующего наложения патча необходимо перейти в корень дерева исходников и выполнить команду:
patch -p1 < our_patch.patch
И после этого получим пропатченное дерево исходников :)
Ядро 2.6.32 выбрано для Long Time Support ( расширенный цикл поддержки )
Радостная новость, поддержка 32 ядра будет еще 2-3 года (у обычных ядер - несколько месяцев), что очень удобно для тех, кто проектирует крупные инсталляции и смотрит на будущее :)
Отладка планировщика ядра
Есть такая штука как /proc/schedstat. Там отображается статистика работы планировщика, для ее активации необходимо опцию CONFIG_SCHEDSTATS ( Collect scheduler statistics ) выставить в Y и пересобрать ядро.
Инкрементальные бэкапы для ядра 2.6.27 / 2.6.32 (эксклюзивная версия!)
Я ранее уже упоминал в блоге замечательный патч от Matt Heaton http://www.mattheaton.com/?p=188, но теперь решил его портировать на 32е ядро и перевести документацию на русский.
Этот патч предоставляет информацию о всех измененных, вновь созданных или подвергшихся изменению прав посредством chmod файлах в системе. Таким образом, эти файлы могут быть забэкаплены без осуществления полного сканирования файловой системы и поиска изменившихся файлов (например, посредством программ rdiff-backup или rsync). Само резервное копирование не входит в задачи этого патча, он только предоставляет список файлов. Бэкап списка изменившихся файлов осуществляете уже Вы сами, это самая легкая часть задачи. Более сложную - формирование спсика изменившихся файлов - решает патч ядра.
В патче нету хеширования, сортировки или фильтрации дубликатов файлов. Это означает, что после того, как файл будет изменен и до того, как вы его забэкапите, он может изменится снова. Таким образом, вы вполне можете получить дубликаты файлов в логе изменений. Чтобы избежать ошибок в поведении бэкап скрипта просто удаляйте дубликаты в нем.
Чтобы использовать все эти замечательные возможности, необходимо применить следующий патч на исходники 2.6.27 ядра с kernel.org После этого у ядра появится два триггера, которые по-умолчанию отключены и система логирования изменившихся файлов не создает нагрузки на систему:
Чтобы включить логгирование, используйте следующие команды:
Либо же можно добавить следующие строки в файл:
После этого необходимо внести коррективы в файл /etc/syslog.conf, чтобы syslog принимал сообщения от ядра (как раз посредством них и будут передаваться измененные файлы) и сохранял их в лог:
После этого, все измененные файлы будут отображаться в логе /var/log/modified.
UPDATE: самостоятельно перенес патч на 2.6.32.8 ядро, вот он, прошу: http://fastvps.googlecode.com/svn/trunk/patches/bluehost-backup-fastvps-edited-patch-2.6.32.diff
Вот мануал по накатываюнию патча на 2.6.32.8 ядро
В итоге должны увидеть нечто вот такое:
Далее собираем ядро.
(с) http://www.mattheaton.com/?p=188
Этот патч предоставляет информацию о всех измененных, вновь созданных или подвергшихся изменению прав посредством chmod файлах в системе. Таким образом, эти файлы могут быть забэкаплены без осуществления полного сканирования файловой системы и поиска изменившихся файлов (например, посредством программ rdiff-backup или rsync). Само резервное копирование не входит в задачи этого патча, он только предоставляет список файлов. Бэкап списка изменившихся файлов осуществляете уже Вы сами, это самая легкая часть задачи. Более сложную - формирование спсика изменившихся файлов - решает патч ядра.
В патче нету хеширования, сортировки или фильтрации дубликатов файлов. Это означает, что после того, как файл будет изменен и до того, как вы его забэкапите, он может изменится снова. Таким образом, вы вполне можете получить дубликаты файлов в логе изменений. Чтобы избежать ошибок в поведении бэкап скрипта просто удаляйте дубликаты в нем.
Чтобы использовать все эти замечательные возможности, необходимо применить следующий патч на исходники 2.6.27 ядра с kernel.org После этого у ядра появится два триггера, которые по-умолчанию отключены и система логирования изменившихся файлов не создает нагрузки на систему:
/proc/sys/fs/bh_logging_user
/proc/sys/fs/bh_logging_root
Чтобы включить логгирование, используйте следующие команды:
echo 1 > /proc/sys/fs/bh_logging_user
echo 1 > /proc/sys/fs/bh_logging_root
Либо же можно добавить следующие строки в файл:
vi /etc/sysctl.conf
fs.bh_logging_user=1
fs.bh_logging_root=1
После этого необходимо внести коррективы в файл /etc/syslog.conf, чтобы syslog принимал сообщения от ядра (как раз посредством них и будут передаваться измененные файлы) и сохранял их в лог:
kern.debug /var/log/modified
После этого, все измененные файлы будут отображаться в логе /var/log/modified.
UPDATE: самостоятельно перенес патч на 2.6.32.8 ядро, вот он, прошу: http://fastvps.googlecode.com/svn/trunk/patches/bluehost-backup-fastvps-edited-patch-2.6.32.diff
Вот мануал по накатываюнию патча на 2.6.32.8 ядро
cd /usr/src/linux-2.6.32.8
wget http://fastvps.googlecode.com/svn/trunk/patches/bluehost-backup-fastvps-edited-patch-2.6.32.diff
patch -p1 < bluehost-backup-fastvps-edited-patch-2.6.32.diff
В итоге должны увидеть нечто вот такое:
patching file fs/compat.c
patching file fs/dcache.c
patching file fs/namei.c
patching file fs/open.c
patching file fs/read_write.c
patching file include/linux/fs.h
patching file kernel/sysctl.c
patching file mm/mmap.c
Далее собираем ядро.
(с) http://www.mattheaton.com/?p=188
Monday, 18 January 2010
Расширенный формат лога Nginx для шаред инстанций с большим числом айпи
log_format vhost_ip_full_format '$remote_addr - $remote_user [$time_local] $host $server_addr $request '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" $request_time-$upstream_response_time';
А также корректируем основной лог ngnx - указываем новый формат:
access_log /var/log/nginx/access.log vhost_ip_full_format;
Перезапускаем nginx:
/etc/init.d/nginx reload
(c) alekciy
Nginx: accept() failed (24: Too many open files) while accepting new connection on
Причина:
Ранее я это делал посредством добавления ulimit -n 10000 в init скрипт, но есть более правильный способ.
Достаточно в конфиг:
На корневой уровень (например, прямо под "worker_processes"), не в http или event блоки, добавить:
И перезапустить nginx:
2010/01/18 21:08:00 [alert] 20014#0: accept() failed (24: Too many open files) while accepting new connection on 0.0.0.0:80
Ранее я это делал посредством добавления ulimit -n 10000 в init скрипт, но есть более правильный способ.
Достаточно в конфиг:
vi /etc/nginx/nginx.conf
На корневой уровень (например, прямо под "worker_processes"), не в http или event блоки, добавить:
worker_rlimit_nofile 100000;
И перезапустить nginx:
/etc/init.d/nginx restart
Бага с ротацией лога yum.log в CentOS 5
-rw------- 1 root root 4982 Jan 15 16:16 yum.log
-rw-r--r-- 1 root root 32947 Dec 29 20:19 yum.log.1
Намек ясен? :) Хоят, возможно, бага имеет место только на серверах с с-панелью, хотя не уверен.
Предпринимателями не становятся, рождаются
Очень долго не мог сформулировать подобное, но у Матта это получилось лучше всех: http://www.mattheaton.com/?p=50
Установка collectl на Debian
Эта утилита является полной заменой таких программ как sar, vmstat, top, atop, iostat и проч. Вот ее отличный обзор от Matt Heaton - http://www.mattheaton.com/?p=166, офсайт программы вот: http://collectl.sourceforge.net/
Идем на страницу загрузок: http://sourceforge.net/projects/collectl/files/
Только вот профита от тулзы я пока не понимаю :)
Идем на страницу загрузок: http://sourceforge.net/projects/collectl/files/
apt-get install ethtool -y
cd /usr/src
wget 'http://downloads.sourceforge.net/project/collectl/collectl/collectl-2.5.1/collectl-2.5.1-src.tar.gz?use_mirror=sunet'
tar -xf collectl-2.5.1-src.tar.gz
cd collectl-2.5.1
./collectl.pl
Только вот профита от тулзы я пока не понимаю :)
Советы хостинг-компаниям от Matt Heaton
Рекомендую к прочтению всем представителям рынка хостинг-услуг: http://www.mattheaton.com/?p=101
CentOS Linux для шаред хостинга от Matt Heaton
Unfortunately, right now the answer is – With a GREAT DEAL of effort. I mentioned earlier that we use CentOS. This is a free rebranded version of Redhat Enterprise Linux which is a server class linux distribution. Meaning it is geared toward customers with a heavy server workload. The problem is the linux kernel they use in CentOS is SLOW, outdated, and certainly not tuned to our workload.
(c) http://www.mattheaton.com/?p=172
Прирост скорости при использовании MySQL на SSD дисках
Прошу: http://www.mattheaton.com/?p=174 Для тех, кто не ходит по ссылкам - практический прирост в пять раз.
2.6.32.3 kernel oops: dquot_transfer
Баг есть: http://bugzilla.kernel.org/show_bug.cgi?id=15051
Судя по жалобам, возникает в случае, если активированы квоты. Сейчас попробую на 33е апнуться, может поможет.
А теперь немного сыскной работы, Changelog 32 ядра (ссылка) и видим там такой патч:
А теперь открываем Chagelog 33 ядра (ссылка) и видим там такой антипатч:
Вот ссылка на патч от Jan Kara.
А вот и сам патч:
Ани комментс? :) Так что осталось выдрать этот патч из 33 ветки и накатить на 32 ядро :)
Update: патч найден и накачен, все окей, проблема была именно в этом, по ссылке в багзилле ядра также дал ссылки на патч.
Update: фикс принят, но собстна он итак был в "next stable", но все равно очень приятно :)
Update: вышло 2.6.32.4, где баг испарвлен.
Судя по жалобам, возникает в случае, если активированы квоты. Сейчас попробую на 33е апнуться, может поможет.
А теперь немного сыскной работы, Changelog 32 ядра (ссылка) и видим там такой патч:
commit bbf245072d81e512cc88535379ae6edb5d08f420
Author: Dmitry Monakhov
Date: Mon Dec 14 15:21:13 2009 +0300
quota: decouple fs reserved space from quota reservation
commit fd8fbfc1709822bd94247c5b2ab15a5f5041e103 upstream.
Currently inode_reservation is managed by fs itself and this
reservation is transfered on dquot_transfer(). This means what
inode_reservation must always be in sync with
dquot->dq_dqb.dqb_rsvspace. Otherwise dquot_transfer() will result
in incorrect quota(WARN_ON in dquot_claim_reserved_space() will be
triggered)
This is not easy because of complex locking order issues
for example http://bugzilla.kernel.org/show_bug.cgi?id=14739
The patch introduce quota reservation field for each fs-inode
(fs specific inode is used in order to prevent bloating generic
vfs inode). This reservation is managed by quota code internally
similar to i_blocks/i_bytes and may not be always in sync with
internal fs reservation.
Also perform some code rearrangement:
- Unify dquot_reserve_space() and dquot_reserve_space()
- Unify dquot_release_reserved_space() and dquot_free_space()
- Also this patch add missing warning update to release_rsv()
dquot_release_reserved_space() must call flush_warnings() as
dquot_free_space() does.
А теперь открываем Chagelog 33 ядра (ссылка) и видим там такой антипатч:
commit 05b5d898235401c489c68e1f3bc5706a29ad5713
Author: Jan Kara
Date: Wed Jan 6 18:03:36 2010 +0100
quota: Fix dquot_transfer for filesystems different from ext4
Commit fd8fbfc1 modified the way we find amount of reserved space
belonging to an inode. The amount of reserved space is checked
from dquot_transfer and thus inode_reserved_space gets called
even for filesystems that don't provide get_reserved_space callback
which results in a BUG.
Fix the problem by checking get_reserved_space callback and return 0 if
the filesystem does not provide it.
CC: Dmitry Monakhov
Signed-off-by: Jan Kara
Вот ссылка на патч от Jan Kara.
А вот и сам патч:
index dea86ab..3fc62b0 100644 (file)
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -1377,6 +1377,9 @@ static void inode_sub_rsv_space(struct inode *inode, qsize_t number)
static qsize_t inode_get_rsv_space(struct inode *inode)
{
qsize_t ret;
+
+ if (!inode->i_sb->dq_op->get_reserved_space)
+ return 0;
spin_lock(&inode->i_lock);
ret = *inode_reserved_space(inode);
spin_unlock(&inode->i_lock);
Ани комментс? :) Так что осталось выдрать этот патч из 33 ветки и накатить на 32 ядро :)
Update: патч найден и накачен, все окей, проблема была именно в этом, по ссылке в багзилле ядра также дал ссылки на патч.
Update: фикс принят, но собстна он итак был в "next stable", но все равно очень приятно :)
Update: вышло 2.6.32.4, где баг испарвлен.
Subscribe to:
Posts
(
Atom
)