Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Bogdan bog...@gmail.com wrote: [-- text/plain, кодировка base64, кодировка: KOI8-R, 34 строк --] Добрый вечер. Бэклог в php-fpm я отключил в силу того, что не был полностью уверен, идёт ли речь о tcp-бэклоге, либо просто о некой внутренней очереди. Параметры sysctl (сверх стандартных) следующие: net.core.rmem_default=16777216 net.core.netdev_max_backlog=262144 net.core.somaxconn=262144 net.ipv4.tcp_syncookies=1 ^^^ Это то зачем ??? net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144^M net.ipv4.ip_local_port_range=1024 65535 net.ipv4.tcp_tw_reuse=1 netstat -s покажи -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6e5ema-48h@woofie.cef.spbstu.ru
Re: Разный размер директории, после lsync
Не всегда если использовать --inline то не создается временный файл \ --- Старший Системный Администратор Алексей Шалин ОсОО Хостер kg - http://www.hoster.kg ул. Ахунбаева 123 (здание БГТС) h...@hoster.kg -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/219145956.20131126172...@hoster.kg
Re: Разный размер директории, после lsync
Alexey Shalin - Artem Chuprina @ Tue, 26 Nov 2013 17:29:49 +0600: AS Не всегда AS если использовать --inline то не создается временный файл В обсуждаемой конфигурации, если я не ошибаюсь, оно не используется. И я бы сказал, это правильно... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87haazxuff@wizzle.ran.pp.ru
LVM-raid ws. md-raid на гипервизоре
Здравствуйте, коллеги! Собираюсь разворачивать очередной гипервизор на KVM (Debian 7) и опять возник вопрос по дисковой подсистеме. К примеру, имеется 2 жестких диска размером 2тб. Наиболее очевидным кажется отдать оба диска под зеркало md и затем это зеркало целиком скормить под LVM - сделать lvm-том под корень (без отдельного /boot, ибо grub2 умеет грузиться в таком варианте), том для подкачки и нарезать томов для виртуалок - в итоге имеем преимущества резервирования md и гибкость LVM. НО! По опыту использования такого варианта (Ubuntu 12.04), в случае проблем с жестким диском и, соответственно, развале рейда, синхронизируется такой рейд чень долго. А в случае, если проблема случилась при загрузке гипервизора - система не загружается, пока не сребилдится рейд (все настройки в mdadm.conf по умолчанию). Сервак с такой проблемой пришел с винтами из неудачной партии - на два диска из четырех постоянно ругается smartd, НО ремапов нет и по факту диски живые, однако за 1,5 года использования ловил 4-5 раз описанную выше проблему. После ребилда несколько месяцев все опять хорошо. Да, многие скажут, что на сервере непростительно держать такие винты и т.д., это все понятно, но имеем то, что имеем (по гарантии их не принимают, ибо смарт-тестирование они проходят и ремапов нет, есть только Current_Pending_Sector и Offline_Uncorrectable) Так вот - возникло желание уменьшить рейды. В идеале - отдельный рейд под каждую сущность (корень, свап, виртуалка1, виртуалка2 и т.д.). Чтобы в случае проблемы с секторами страдала бы только одна сущность, а не весь массив. Отсюда возник очевидный вывод - использовать lvm raid и вообще отказаться от md. Разбил я винты так - один раздел на весь диск под LVM PV, поставил систему на lvm-том и потом преобразовал его в raid1 (сразу при установке нельзя). В файле /etc/initramfs-tools/modules должны быть строки dm_raid и raid1, после чего надо пересобрать initrd, иначе система не загрузится). Далее я начал эксперименты. Собственно продлились они недолго - при физическом удалении винта, lvm-том переходит в режим только для чтения со всеми вытекающими. После перезагрузки система не загружается. После возвращения винта, все норм. Отсюда вопрос - можно ли настроить lvm raid так, чтобы он вел себя как md, а именно, просто переходил бы в состояние degraded, но продолжал бы работать на запись в том числе и не мешал загрузке системы. Устроит и компромисный вариант - md под корень и свап, а виртуалки создавать на lvm-рейдах, но это не решит проблему в случае факапа - гипервизор продолжит функционирование, ибо на md, а вот виртуалки перейдут в read-only - а нафига мне гипервизор без виртуалок. Вариант рассматриваю, если у lvm raid проблема именно с корневым разделом. Или может еще что-нибудь на данную тему посоветуете? Запостил вопрос на запостил вопрос сначала сюда http://www.opennet.ru/openforum/vsluhforumID1/95228.html а потом вспомнил про рассылку -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/17171385470...@web11h.yandex.ru
Стоп Аллочка ,хватит жрать!
Bogdana, мои поздравления Результат просто изумительный Выглядите замечательно!!! Конечно то же имела планы проверить этот кофе зеленый который мне так хвалили на работе, но до сего времени колебалась! После этаких снимоков и событий все сомнения отвалились! Заказываю немедля не долго думая! http://goo.gl/SLz3uB Возможно еще разок ссылку на лицензионную версию?
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Добрый день. Синкуки - сервер доступен в интернете напрямую, syn flood на tcp/80 периодически случался. Судя по dmesg синкуки активируются только на 80 порт. Поптался под нагрузкой отключить синкуки - не помогло. # netstat -s Ip: 680437848 total packets received 0 forwarded 5 with unknown protocol 0 incoming packets discarded 680434468 incoming packets delivered 1777159635 requests sent out 363 fragments dropped after timeout 5485 reassemblies required 2406 packets reassembled ok 365 packet reassembles failed 4 fragments failed Icmp: 592365 ICMP messages received 1623 input ICMP message failed. ICMP input histogram: destination unreachable: 439442 timeout in transit: 29851 wrong parameters: 1 source quenches: 173 redirects: 3594 echo requests: 117976 144005 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 25816 time exceeded: 213 echo replies: 117976 IcmpMsg: InType3: 439442 InType4: 173 InType5: 3594 InType8: 117976 InType11: 29851 InType12: 1 OutType0: 117976 OutType3: 25816 OutType11: 213 Tcp: 335720334 active connections openings 475986193 passive connection openings 611418 failed connection attempts 2948223 connection resets received 12328 connections established 680146150 segments received 1976798623 segments send out 80770653 segments retransmited 2023767 bad segments received. 9920587 resets sent Udp: 14213 packets received 26382 packets to unknown port received. 0 packet receive errors 14259 packets sent UdpLite: TcpExt: 27465459 SYN cookies sent 33796620 SYN cookies received 7975762 invalid SYN cookies received 389136 resets received for embryonic SYN_RECV sockets 811 ICMP packets dropped because they were out-of-window 247 ICMP packets dropped because socket was locked 228252760 TCP sockets finished time wait in fast timer 4728737 time wait sockets recycled by time stamp 1520033 packets rejects in established connections because of timestamp 651613807 delayed acks sent 153290 delayed acks further delayed because of locked socket Quick ack mode was activated 15636235 times 15720991 times the listen queue of a socket overflowed 15720991 SYNs to LISTEN sockets dropped 3361873905 packets directly queued to recvmsg prequeue. 2698661925 bytes directly in process context from backlog 2362850595 bytes directly received in process context from prequeue 1310810975 packet headers predicted 2376025214 packets header predicted and directly queued to user 2168271888 acknowledgments not containing data payload received 3603412648 predicted acknowledgments 4468 times recovered from packet loss due to fast retransmit 751825 times recovered from packet loss by selective acknowledgements 1614 bad SACK blocks received Detected reordering 18406 times using FACK Detected reordering 11064 times using SACK Detected reordering 150 times using reno fast retransmit Detected reordering 9035 times using time stamp 18658 congestion windows fully recovered without slow start 27425 congestion windows partially recovered using Hoe heuristic 10709583 congestion windows recovered without slow start by DSACK 15517441 congestion windows recovered without slow start after partial ack 1346870 TCP data loss events TCPLostRetransmit: 171181 6511 timeouts after reno fast retransmit 1538949 timeouts after SACK recovery 246600 timeouts in loss state 2233810 fast retransmits 322817 forward retransmits 2790644 retransmits in slow start 54282107 other TCP timeouts 1051 classic Reno fast retransmits failed 106611 SACK retransmits failed 15829915 DSACKs sent for old packets 1240 DSACKs sent for out of order packets 17886120 DSACKs received 8409 DSACKs for out of order packets received 951323 connections reset due to unexpected data 32014 connections reset due to early user close 921618 connections aborted due to timeout TCPSACKDiscard: 4123 TCPDSACKIgnoredOld: 265129 TCPDSACKIgnoredNoUndo: 1883713 TCPSpuriousRTOs: 8944 TCPSackShifted: 1957011 TCPSackMerged: 2434447 TCPSackShiftFallback: 9448212 TCPBacklogDrop: 155 TCPReqQFullDoCookies: 35379950 TCPReqQFullDrop: 643501 TCPChallengeACK: 1778474 TCPSYNChallenge: 2068557 IpExt: InBcastPkts: 24 InOctets: -648479550 OutOctets: -338174407 InBcastOctets: 10352 # ss -s Total: 17098 (kernel 17789) TCP: 123227 (estab 12438, closed 105609, orphaned 601, synrecv 0, timewait 105609/0), ports 10570 Transport Total IPIPv6 * 17789 - - RAW 0 0 0 UDP 9 5 4 TCP 17618
Re: Разный размер директории, после lsync
On Mon, Nov 25, 2013 at 09:35:38AM +0600, Alexey Shalin wrote: делаю сихронизацию двух каталогов синк проходит без проблем, но если сделать написал скрипт, который бы делал сравнивал md5sum файлов ... все md5суммы совпали Это, скорее всего, размер метаданных каталогов влияет. Они при создании файлов в каталоге разрастаются и потом при удалении фалйлов не уменьшаются. Вот пример: 1) создание каталога для теста mkdir 10k 2) создание в нём 10 тыс файлов нулевого размера $ for i in `seq -w 1 1`; do touch 10k/$i; done 3) каталог занимает 256К без учета размера файлов $ ls -ld 10k drwxr-xr-x 2 apavel apavel 262144 Nov 26 23:53 10k/ 4) удаление всех файлов из каталога $ rm 10k/* 5) пустой он всеравно занимает 256K $ ls -ld 10k drwxr-xr-x 2 apavel apavel 262144 Nov 26 23:53 10k/ 6) если его скопировать, то копия будет 4K $ cp -pr 10k/ copy $ ls -ld 10k copy drwxr-xr-x 2 apavel apavel 262144 Nov 26 23:53 10k/ drwxr-xr-x 2 apavel apavel 4096 Nov 26 23:53 copy/ $ du -ks 10k copy 256 10k 4 copy Вот и вся причина разницы в выводе du между оригиналом и копией. PS На ноутбучном диске 10k файлов создавались слишком долго, но на примонтированном с tmpfs через loop файле все прошло заметно бодрее :) $ df -T . Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/loop0 ext4 1995664 36008 1858280 2% /mnt -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131126201045.gc17...@vesuvius.wapper.ru
три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии без выключения компьютера?
... Если конечно такое возможно. Три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии ? На рабочей системе с тремя дисками в raid1: sda1,sdb1,sdc1 = md0, /boot sda2,sdb2,sdc2 = md1, lvm pv с именем - sysraid with rootfs, home, var/log, var/lib/lxc and etc logical volumes of server делаю: grub-install /dev/sdc mdadm /dev/md0 --fail /dev/sdc1 mdadm /dev/md0 --remove /dev/sdc1 mdadm /dev/md1 --fail /dev/sdc2 mdadm /dev/md1 --remove /dev/sdc2 sdc - диск подключенный через usb 3.0 dock станцию. выключаю компьютер, вынимаю sda,sdb оставляю только sdc, который выкинул из массива grub грузиться и даже с меню. Но после нажатия Enter на строке обычной загрузки системы или строке восстановления системы - компьютер почти сразу уходит в ребут. Если загрузится с CD диска, то вижу следующее: cat /proc/mdstat md126inactivesda2[2](S) md127inactivesda1[3](S) mdadm --stop /dev/md126 mdadm --stop /dev/md127 а после собрать их так: mdadm -A --scan То они собираются и работают с всего один диском. Но файловые системы не монтируются, mount ругается на The superblock could not be read or does not describe a correct ext4 filesystem. If the device is valid and it really contains an ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Пробовал делать e2fsck -b 8193 /dev/sysraid/volume_name не помогает. Очевидно, что надо выбрасывать этот третий диск из массива когда ФС не смонтированы. Или что то еще ? Вопрос в том, как это лучше делать ? Самый простой вариант(на работающем массиве из трех синхронизированных дисках) - отключить сервер, вытащить 3-ий диск. Включить сервер. Есть идея сделать это через переключение уровней запуска. Но не ясно приведет ли это к желаемому результату. Кажется это какой-то долгий и сильно сложный путь. Второй вариант - без mdadm, точнее скрипт, который создаст нужную разметку на третем винте, сделает снапшоты, и скопирует логические тома. Но его тоже будет не просто написать. Откровенно говоря - на знаю куда копать и что делать дальше. -- -- Best regards, Vladimir Skubriev -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529587b1.2080...@skubriev.ru
Re: три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии без выключения компьютера?
а если просто тупо выдернуть usb-винт, без вывода из рейда? я думаю достаточно стопануть все базы данных и сделать sync перед этим. Но возможно проблема тут глубже и связана с версией mdadm в момент создания рейда, есть там нюансы. Возможно что без пересоздания рейда с нуля свежим mdadm проблему не решить. Если что скрипт бэкапа в общем то не сложен, у меня есть примерно похожее на питоне, бэкаплю lvm-тома. Ну а /boot тупо скопировать можно 27.11.2013, 09:49, Vladimir Skubriev vladi...@skubriev.ru: ... Если конечно такое возможно. Три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии ? На рабочей системе с тремя дисками в raid1: sda1,sdb1,sdc1 = md0, /boot sda2,sdb2,sdc2 = md1, lvm pv с именем - sysraid with rootfs, home, var/log, var/lib/lxc and etc logical volumes of server делаю: grub-install /dev/sdc mdadm /dev/md0 --fail /dev/sdc1 mdadm /dev/md0 --remove /dev/sdc1 mdadm /dev/md1 --fail /dev/sdc2 mdadm /dev/md1 --remove /dev/sdc2 sdc - диск подключенный через usb 3.0 dock станцию. выключаю компьютер, вынимаю sda,sdb оставляю только sdc, который выкинул из массива grub грузиться и даже с меню. Но после нажатия Enter на строке обычной загрузки системы или строке восстановления системы - компьютер почти сразу уходит в ребут. Если загрузится с CD диска, то вижу следующее: cat /proc/mdstat md126 inactive sda2[2](S) md127 inactive sda1[3](S) mdadm --stop /dev/md126 mdadm --stop /dev/md127 а после собрать их так: mdadm -A --scan То они собираются и работают с всего один диском. Но файловые системы не монтируются, mount ругается на The superblock could not be read or does not describe a correct ext4 filesystem. If the device is valid and it really contains an ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Пробовал делать e2fsck -b 8193 /dev/sysraid/volume_name не помогает. Очевидно, что надо выбрасывать этот третий диск из массива когда ФС не смонтированы. Или что то еще ? Вопрос в том, как это лучше делать ? Самый простой вариант(на работающем массиве из трех синхронизированных дисках) - отключить сервер, вытащить 3-ий диск. Включить сервер. Есть идея сделать это через переключение уровней запуска. Но не ясно приведет ли это к желаемому результату. Кажется это какой-то долгий и сильно сложный путь. Второй вариант - без mdadm, точнее скрипт, который создаст нужную разметку на третем винте, сделает снапшоты, и скопирует логические тома. Но его тоже будет не просто написать. Откровенно говоря - на знаю куда копать и что делать дальше. -- -- Best regards, Vladimir Skubriev -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529587b1.2080...@skubriev.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/376151385533...@web22j.yandex.ru
Re: три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии без выключения компьютера?
27.11.2013 09:48, Vladimir Skubriev пишет: ... Если конечно такое возможно. Три диска в зеркале - как отсоединить один диск, чтобы файловые системы на нем были в консистентном состоянии ? На рабочей системе с тремя дисками в raid1: sda1,sdb1,sdc1 = md0, /boot sda2,sdb2,sdc2 = md1, lvm pv с именем - sysraid with rootfs, home, var/log, var/lib/lxc and etc logical volumes of server делаю: grub-install /dev/sdc mdadm /dev/md0 --fail /dev/sdc1 mdadm /dev/md0 --remove /dev/sdc1 mdadm /dev/md1 --fail /dev/sdc2 mdadm /dev/md1 --remove /dev/sdc2 sdc - диск подключенный через usb 3.0 dock станцию. выключаю компьютер, вынимаю sda,sdb оставляю только sdc, который выкинул из массива grub грузиться и даже с меню. Но после нажатия Enter на строке обычной загрузки системы или строке восстановления системы - компьютер почти сразу уходит в ребут. Если загрузится с CD диска, то вижу следующее: cat /proc/mdstat md126inactivesda2[2](S) md127inactivesda1[3](S) Ваша проблема почти наверняка связана с конфигурацией mdadm. На что стоит посмотреть: 1. Соответствию файла конфигурации в initrd и в /etc/mdadm. Если вы не выполняли принудительного обновления initrd после перестройки массива, то в initrd будет старая конфигурация, которая может не позволить собраться новому массиву. Рекомендуется после обновления массива делать update-initramfs -u. Это вроде должно решить и проблему 2 2. Соответствие конфигурации mdadm и реальных массивов. Возможны ситуации, когда вы перестроили массивы, а в файле конфигурации остались старые данные 3. Содержимое файла mdadm.conf - для ваших массивов не должно быть указано имя хоста - это может создавать проблемы -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52959577.6070...@darkmike.ru
