Re: [freebsd] mysql MyIsam + ZFS
Может я чего то не увидел,но my.cnf одинаковый? по моему опыту с теми параметрами, которые Вы указали для zfs скорость сильно различаться не должна Еще такой момент Мускульный запрос на "горячем" сервере может браться из кеша, а на тесте - соответственно нет, кеши не прогреты совсем. Так что имхо,но тест не очень информативный 12 января 2015 г., 9:55 пользователь Vasiliy P. Melnik написал: > я в свое время отказался от перевода оракла на солярис именно из-за > тормозов. Ну то есть у меня старый сервер базу импортирует быстрее, чем > новый > > 12 января 2015 г., 0:06 пользователь Vyacheslav Biruk > написал: > > Здравствуйте, >> >> планируя переводить сервер на ZFS я видел, что есть проблемы с mysql, >> сразу приводилось как нада тюнать, но что будут ТАКИЕ проблемы я не >> подозревал :( >> >> имеем >> FreeBSD 10.1-RELEASE >> mysql55-server-5.5.41 >> и табличку >> -rw-rw 1 mysql mysql 1248723788 11 січ 08:00 wp_comments.MYD >> -rw-rw 1 mysql mysql32954368 11 січ 08:01 wp_comments.MYI >> -rw-rw 1 mysql mysql9284 11 січ 08:00 wp_comments.frm >> >> запрос вида >> SELECT comment_ID FROM wp_comments WHERE comment_post_ID = '22' AND >> comment_approved != 'trash' AND ( comment_author = 'bla bla bla bla' OR >> comment_author_email = 'bla...@gmail.com' ) AND comment_content = >> 'I havent checked in here' LIMIT 1; >> >> на UFS2 выполнялся порядка (2.09 sec) >> на ZFS - (2 min 7.33 sec) >> >> раздел создаю командой >> zfs create -o atime=off -o exec=off -o setuid=off -o recordsize=8K -o >> primarycache=metadata -o mountpoint=/mnt/zfs mysql/mysql >> >> vfs.zfs.prefetch_disable: 1 >> >> ARC/L2ARC/ZIL - дефолтные >> >> пробовал игратся key_buffer/myisam_sort_buffer - поставил разер 1G - >> запрос выполнился в два раза быстрее - (1 min 34.91 sec) >> >> при innoodb на recordsize=8K результат получше - (42.53 sec), но до >> оригинала далеко, да и не все таблицы могу пеервести в innodb >> >> можно ли еще чтото подкрутить для ZFS или таки mysql ставить на ufs? >> >> >> PS. если я хочу переразбить диск - у меня система перенесется командами >> zfs snapshot -r pool@now >> zfs send pool@now | mbuffer -m 128M | zfs receive pool2 >> >> или нада zfs send -R юзать? >> >> >
[freebsd] Fwd: proxy_store не сохраняет файлы
Добрый день
Подскажите плз, что я делаю не так
имеется основной сервер хранения (storage) и фронтенд (img)
на фронтенде настроено
server {
listen *:80;
server_name img.site1.com img-a6.site1.com ;
root /home/site1/site1.com;
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|html|txt)$ {
root /home/site1/site1.com/;
try_files $uri $uri/ @fallback;
error_log /home/site1/logs/site1.com-img-error.log warn ;
}
location @fallback
{
proxy_pass http://storage.site1.com;
proxy_store /home/site1/site1.com/$request_uri;
root /home/site1/site1.com;
proxy_store_access user:rw group:rw all:rw;
error_log /home/site1/logs/fallback-error.log warn ;
access_log /home/site1/logs/fallback-access.log ;
}
}
но при этом в /home/site1/site1.com пусто и он все равно за каждым
запросом обращается на storage
nginx version: nginx/1.6.2
[freebsd] Re: [freebsd] Скобки в hostname
Можно )) Но мне пришел такой вот тазик, это не я ) 5 ноября 2014 г., 13:26 пользователь Anton Sayetsky написал: > А ещё можно гвозди микроскопом забивать. > http://tools.ietf.org/html/rfc1123#page-13 > > 5 ноября 2014 г., 13:18 пользователь greenh написал: > > Добрый день. > > Хотел бы просто поделиться наблюдением > > Если во freebsd hostname использовать скобки (что нить типа > server1(backup) > > ), то неожиданно ломаются rc скрипты и выдают странные матюки. >
[freebsd] Скобки в hostname
Добрый день. Хотел бы просто поделиться наблюдением Если во freebsd hostname использовать скобки (что нить типа server1(backup) ), то неожиданно ломаются rc скрипты и выдают странные матюки.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Перевод времени в MSK зоне
Обновил zoneinfo - помогло. Всем спасибо 29 октября 2014 г., 12:56 пользователь Anton Yuzhaninov написал: > On 10/29/14 13:48, Anton Sayetsky wrote: > >> Да, кстати, zoneinfo при установке говорит, что tzsetup надо запускать. >> Нет бы >> симлинк сделать вместо копирования файла... >> > > Копирование делается на тот случай если / и /usr живут на разных файловых > системах и когда смотирован / а /usr ещё нет, правильно время уже нужно. >
[freebsd] Re: [freebsd] Перевод времени в MSK зоне
Я ставил zoneinfo из портов, но мне это не помогло. Возможно это были не очень свежие порты, хотя я стараюсь держать дерево актуальным. Сейчас обновлюсь и проверю 29 октября 2014 г., 12:38 пользователь Anton Sayetsky написал: > https://www.freebsd.org/security/advisories/FreeBSD-EN-14:10.tzdata.asc > > 29 октября 2014 г., 12:33 пользователь greenh написал: > > Всем привет > > Подскажите плз, что я делаю не так? > > есть сервер > > > > #date > > Wed Oct 29 14:31:46 MSK 2014 > > > > #ntpdate 0.europe.pool.ntp.org > > 29 Oct 14:32:54 ntpdate[604]: adjust time server 46.22.223.220 offset > > 0.047302 sec > > > > Хотя на самом деле в России в msk на час меньше, т.е. он просто > игнорирует > > перевод. > > >
[freebsd] Перевод времени в MSK зоне
Всем привет Подскажите плз, что я делаю не так? есть сервер #date Wed Oct 29 14:31:46 MSK 2014 #ntpdate 0.europe.pool.ntp.org 29 Oct 14:32:54 ntpdate[604]: adjust time server 46.22.223.220 offset 0.047302 sec Хотя на самом деле в России в msk на час меньше, т.е. он просто игнорирует перевод.
[freebsd] Re: [freebsd] Re: [freebsd] Мониторинг с уведомлением СМС
Еще можно сделать уведомления на почту и их проверять телефоном с громким звуковым уведомлением. Мы все это уже перепробовали и для нас оказалось самым удобным использование смс-гейта 16 июля 2014 г., 18:05 пользователь Mykola Dzham написал: > On Jul 15, 2014, at 15:22, Vladislav V. Prodan > wrote: > > > > На Украине вижу только у Киевстара услугу email to sms. (с некоторыми > ограничениями) > > > > Следующий вариант : > > дешевый телефон с RS232 или USB (Android?) > > для отправки SMS > > для почтовых варнингов > > для IP туннеля > > > > > > Какие еще есть альтернативы услуги (email to sms) ? > > Какие варианты дешевых телефонов/модемов для второго варианта? > > Еще одна альтернатива это не использовать email to sms, а поставить на > телефон клиент > для своей системы мониторинга и пустить этого клиента по интернету к > системе мониторинга: > исключаем лишнее звено и даже добавляем мониторинг самой системы > мониторинга - если > система мониторинга сдохнет, то клиент ругнется. > > -- > LEFT-(UANIC|RIPE) > >
[freebsd] Re: [freebsd] Мониторинг с уведомлением СМС
Отказался от попыток слать СМС самостоятельно и сейчас использую смс гейт smsimple.ru и http://alphasms.ua/ 15 июля 2014 г., 16:19 пользователь Yuri Kurenkov написал: > 15.07.2014 16:22, Vladislav V. Prodan пишет: > > Следующий вариант : >> дешевый телефон с RS232 >> > > Siemens TC35 и comms/scmxx более 11 лет на посту. И они еще в продаже > есть. > > -- > Yuri V. Kurenkov [YVK9-RIPN,YVK11-RIPE] > Home: +7-8634-64-27-63 > Mobile: +7-928-1725845 > ICQ UIN:21666578 > Skype: yuri.kurenkov >
[freebsd] Re: [freebsd] Re: [freebsd] hadoop и cloudera manager
В общем hadoop живет под линуксом. печально 8 июля 2014 г., 19:51 пользователь Alexander Yerenkow написал: > > > > 8 июля 2014 г., 18:12 пользователь Anton Yuzhaninov > написал: > > On 07/08/14 18:41, greenh wrote: >> >>> Господа, а кто нить приручал cloudera manager под FreeBSD и возможно ли >>> это? или >>> придется ставить и настраивать hadoop врукопашную? >>> >> >> C hadoop на FreeBSD всё достаточно грустно... >> >> Сейчас в нашей конторе пока еще используется Hadoop 0.20.2 CDH3 под >> FreeBSD (но есть планы по миграции на Linux). Поставлен из самописного >> порта, без cloudera manager. >> >> Работает он только с java/jdk16 который из портов уже давно удалили (мы >> таскаем патченый /usr/ports с этим портом). >> >> С openjdk и 1.6 и 1.7 работает только HDFS, а MapReduce под нагрузкой >> плодит зависшие процессы из за чего довольно быстро превращается в тыкву. >> >> Проблема внутри одной из используемых библиотек - вроде бы Jetty но точно >> не помню (могу поискать если интересно). В Hadoop используется очень старая >> версия этой библиотеки (с кучей известных багов, исправленных в более >> свежих версиях). Смотрел свежие версии Hadoop - там такая же старая версия >> этой библиотеки. Видимо под Linux все эти баги проявляются достаточно редко >> и разработчики Hadoop уже несколько лет игнорируют тикет в Hadoop JIRA по >> обновлению этой самой библиотеки. Заменить эту библиотеку на свежую версию >> сходу не получится - за прошедшие N лет у неё успел измениться API. >> >> Пробовал на FreeBSD запускать более свежие версии Hadoop - та же проблема >> в том же месте. >> > > Вы про это? > > https://github.com/freebsd/freebsd-ports/blob/master/devel/hadoop2/Makefile#L78 > > > -- > Regards, > Alexander Yerenkow >
[freebsd] Re: [freebsd] hadoop и cloudera manager
а сам hadoop2 хоть как то живет, или это совсем извращение? 8 июля 2014 г., 17:47 пользователь Alexander Yerenkow написал: > Нативок хадупских нет под фрю + менеджер не очень понимает системы для > которых у него нет скриптов управления. > > В теории это всё можно, но не для управления, а для мониторинга максимум, > и то перепилить придётся много чего. > > Лучше вложите силы в что-то опенсорсное, и запилите поддержку фри, > например рекомендую глянуть в сторону Apache Ambari. > > > > 8 июля 2014 г., 17:41 пользователь greenh написал: > > Господа, а кто нить приручал cloudera manager под FreeBSD и возможно ли >> это? или придется ставить и настраивать hadoop врукопашную? >> > > > > -- > Regards, > Alexander Yerenkow >
[freebsd] hadoop и cloudera manager
Господа, а кто нить приручал cloudera manager под FreeBSD и возможно ли это? или придется ставить и настраивать hadoop врукопашную?
[freebsd] Re: [freebsd] В чем хранить статистику
На s3 выборки делать не получится.. разве что бекапить 22 мая 2014 г., 16:04 пользователь Serge Negodyuck написал: > mongodb, riak, project voldemort, hadoop+shark, hadoop+cassandra, > hadoop+., > > Но я бы просто ротировал логи в файлах допустим ежечасно или каждые сутки, > и загружал бы их на amazon s3, для надежности. > > > 22 мая 2014 г., 15:01 пользователь greenh написал: > > Народ, вот подскажите, а в чем естьсмысл хранить статистику, при условии >> что дневной прирост составляет 30-100 лямов записей >> Желательно иметь возможность пусть и медленно, но огромным массивам, типа >> "за последний месяц" >> То есть, грубо говоря, нужен способ хранения примерно 500гиг-1тб базы, >> при этом с возможностью быстрой вставки данных, вменяемой устойчивостью к >> отказам и рассыпанию. Есть что нить вменяемое для таких задач? SQL/noSQL - >> не имеет значения >> > >
[freebsd] В чем хранить статистику
Народ, вот подскажите, а в чем естьсмысл хранить статистику, при условии что дневной прирост составляет 30-100 лямов записей Желательно иметь возможность пусть и медленно, но огромным массивам, типа "за последний месяц" То есть, грубо говоря, нужен способ хранения примерно 500гиг-1тб базы, при этом с возможностью быстрой вставки данных, вменяемой устойчивостью к отказам и рассыпанию. Есть что нить вменяемое для таких задач? SQL/noSQL - не имеет значения
[freebsd] Re: [freebsd] Что это значит?
Это чей лог? Чем занимается машина? Что за ос? 2014-04-23 10:18 GMT+03:00 <6...@cryptolab.net>: > IP 80.60.x.x > z.z.z.z: ICMP redirect 0.0.0.0 to host 195.190.x.x, length > 36 > где "z.z.z.z" - серый адрес > -- >
[freebsd] Re: [freebsd] Некорректная работа Mysql-сервера после вылета диска из массива
А снести их через kill -9 и запустится с force_repair=4 (или как там его) не пробовал? 2014-04-23 0:26 GMT+03:00 Vladislav V. Prodan : > Вылетел один винт в массиве. > После рестарта сервера Mysql не поднимается > > 140423 0:15:46 [Note] Plugin 'FEDERATED' is disabled. > 140423 0:15:46 InnoDB: Initializing buffer pool, size = 6.6G > 140423 0:15:47 InnoDB: Completed initialization of buffer pool > InnoDB: The log sequence number in ibdata files does not match > InnoDB: the log sequence number in the ib_logfiles! > 140423 0:15:48 InnoDB: Database was not shut down normally! > InnoDB: Starting crash recovery. > InnoDB: Reading tablespace information from the .ibd files... > InnoDB: Restoring possible half-written data pages from the doublewrite > InnoDB: buffer... > InnoDB: Transaction 0 2326200221 was in the XA prepared state. > InnoDB: 1 transaction(s) which must be rolled back or cleaned up > InnoDB: in total 0 row operations to undo > InnoDB: Trx id counter is 0 2326201600 > InnoDB: Last MySQL binlog file position 0 7520, file name > ./mysql-bin.029690 > InnoDB: Starting in background the rollback of uncommitted transactions > 140423 0:17:49 InnoDB: Rollback of non-prepared transactions completed > 140423 0:17:50 InnoDB: Started; log sequence number 19 3123592930 > /usr/local/libexec/mysqld: File 'Data locked: NO' not found (Errcode: 2) > 140423 0:17:50 [ERROR] Failed to open log (file 'Data locked: NO', errno > 2) > 140423 0:17:50 [ERROR] Could not open log file > 140423 0:17:50 [ERROR] Can't init tc log > 140423 0:17:50 [ERROR] Aborting > > 140423 0:17:50 InnoDB: Starting shutdown... > > В итоге два мускульных процесса подвисли. > > mysql66500,0 0,0 14528 2200 ?? Is0:15 > 0:00,02 /bin/sh /usr/local/bin/mysqld_safe > --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql > --datadir=/var/db/mysql --pid-file=/var/db/mysql/beastie.XXX.com.pid > mysql69090,0 3,9 8384780 966764 ?? I 0:15 > 0:01,68 /usr/local/libexec/mysqld > --defaults-extra-file=/var/db/mysql/my.cnf --basedir=/usr/local > --datadir=/var/db/mysql --log-error=/var/db/mysql/beastie.XXX.com.err > --open-files-limit=20 --pid-file=/var/db/mysql/beastie.XXX.com.pid > --socket=/tmp/mysql.sock --port=3306 > > > Как чинить - не понятно > > > apr-ipv6-devrandom-gdbm-db42-mysql51-1.4.2.1.3.10 Apache Portability > Library > mysql-client-5.1.54_1 Multithreaded SQL database (client) > mysql-scripts-5.1.54_1 Multithreaded SQL database (scripts) > mysql-server-5.1.54_1 Multithreaded SQL database (server) > > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua >
[freebsd] Re: [freebsd] mysql на linux таки быстрее или я не умею что то готовить?
14 марта 2014 г., 10:40 пользователь Slawa Olhovchenkov написал: > On Fri, Mar 14, 2014 at 01:38:49AM +0200, greenh wrote: > > > 14 марта 2014 г., 1:00 пользователь Slawa Olhovchenkov >написал: > > > > > On Fri, Mar 14, 2014 at 12:25:22AM +0200, greenh wrote: > > > > > > > Господа, подскажите плз, неужели mysql на линукс таки быстрее или я > не > > > > совсем не умею готовить фрю > > > > Имеется > > > > linux сервер, о 8 ядрах и 16 гигах оперативки собраный на программном > > > > > > так я не понял -- что за сервер-то? > > > > > > > зеркале. На севере работает связка nginx+php-fpm через tcp сокет и > mysql > > > > 5.1 с нагрузкой 3-5k qps > > > > my.cnf > > > > max_connections = 400 > > > > query_cache_size = 50M > > > > join_buffer_size = 450M > > > > thread_cache_size = 128 > > > > table_cache = 128 > > > > > > > > Рабочие LA<1, user cpu<10% > > > > > > > > > > > > Пытаюсь все это перенести на freebsd сервер с 2 по CPU E5-2420 (24 > ядра) > > > и > > > > тех же 16 гиг (то есть машинка существенно более мощная) > > > > > > у E5-2420 нет 12 ядер. это раз. > > > > > > http://ark.intel.com/ru/products/64617/ProductCollection.aspx?brand=41492 > > Количество ядер6Количество потоков12 > > > > > > > ну и вообще он отстой, это два > > > > > > > Вряд ли два таких камня более отстой чем один i7-2600 > > почему ты стесняешься этой информации? > Стоит UFS2+soft updates, но на raid0 Не думаю, что zfs с учетом нулевого рейда и того, что на старом тазике ВСЕ находится на одном винте как то изменит ситуацию База полностью идентична, так что индексы не при чем
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] mysql на linux таки быстрее или я не умею что то готовить?
14 марта 2014 г., 10:26 пользователь Alexandr написал: > 14.03.2014 10:08, greenh пишет: > > > 14 марта 2014 г., 9:29 пользователь Sergey V. Dyatko < > sergey.dya...@gmail.com> написал: > >> В Fri, 14 Mar 2014 09:19:02 +0200 >> Alexander Yerenkow пишет: >> >> > Если разница столь существенна - то подёргайте explain-ы, может у вас >> > где-то индексы потерялись. >> дергал, идентичный вывод видел я >> >> > Ну и любые тормоза при одинаковом железе почти наверняка есть тормоза >> > FS. Где UFS не блещет обычно, а для ZFS+DB плюсов вроде столько же >> > сколько и минусов, и готовить мускль надо стараться. >> >> ну так о чем и вопрос изначально стоял "как-то по особому нужно >> готовить?" :) >> судя по gstat там fs не нагружена как-то была. при такой большой >> разнице времени выполнения запроса это было бы явно заметно >> >> > >> > Плюс сделайте sort + diff обоих конфигов, чтобы точно видеть их все >> > различия. >> > >> >> конфиг копировался с линаксовой коробки без изменений даже, что и >> вызвало некоторое.. недоумение >> > > Аналогично. Я в первый раз думаю о переходе на линукс > >> >> >>Когда-то натыкался на пост о проблемах выделения памяти mysql на > 9-ке. Автор решил свою проблему (симптомы похожи на ваши) значительным > уменьшением table_open_cache, как это не парадоксально. > Свободной памяти валом
[freebsd] Re: [freebsd] Re: [freebsd] mysql на linux таки быстрее или я не умею что то готовить?
14 марта 2014 г., 9:29 пользователь Sergey V. Dyatko < sergey.dya...@gmail.com> написал: > В Fri, 14 Mar 2014 09:19:02 +0200 > Alexander Yerenkow пишет: > > > Если разница столь существенна - то подёргайте explain-ы, может у вас > > где-то индексы потерялись. > дергал, идентичный вывод видел я > > > Ну и любые тормоза при одинаковом железе почти наверняка есть тормоза > > FS. Где UFS не блещет обычно, а для ZFS+DB плюсов вроде столько же > > сколько и минусов, и готовить мускль надо стараться. > > ну так о чем и вопрос изначально стоял "как-то по особому нужно > готовить?" :) > судя по gstat там fs не нагружена как-то была. при такой большой > разнице времени выполнения запроса это было бы явно заметно > > > > > Плюс сделайте sort + diff обоих конфигов, чтобы точно видеть их все > > различия. > > > > конфиг копировался с линаксовой коробки без изменений даже, что и > вызвало некоторое.. недоумение > Аналогично. Я в первый раз думаю о переходе на линукс > > > > -- > wbr, tiger > >
[freebsd] mysql на linux таки быстрее или я не умею что то готовить?
Господа, подскажите плз, неужели mysql на линукс таки быстрее или я не совсем не умею готовить фрю Имеется linux сервер, о 8 ядрах и 16 гигах оперативки собраный на программном зеркале. На севере работает связка nginx+php-fpm через tcp сокет и mysql 5.1 с нагрузкой 3-5k qps my.cnf max_connections = 400 query_cache_size = 50M join_buffer_size = 450M thread_cache_size = 128 table_cache = 128 Рабочие LA<1, user cpu<10% Пытаюсь все это перенести на freebsd сервер с 2 по CPU E5-2420 (24 ядра) и тех же 16 гиг (то есть машинка существенно более мощная) базу кладу на софтварный raid-0 nginx+php_fpm через unix socket Для теста включаю проксирование через старый сервер на новый и получаю 1. первые 2-3 минут база отъедает до 1500% cpu, затем РЕЗКО падает до 70-100 2. LA в районе 2 нагрузка на винты (судя по gstat) около нуля Сайты отдаются существенно медленее (ожидание до открытия до 7-9 секунд против 2-3 на старом) 3. Среднее потребление user cpu > 20-30% (в основном php) и куча долгих запросов к базе (по 1-2 секунды) чего на старом сервере нет. vmstat -z и netstat -m ничего странного не показываю. Подскажите плз, куда смотреть? my.cnf нового сервера symbolic-links=0 max_connections = 400 query_cache_size = 250M join_buffer_size = 2G thread_cache_size = 128 table_cache = 1228 slow_query_log_file = /var/log/mysql-slow.log long_query_time = 1 key_buffer_size = 1560M skip-innodb_doublewrite max_allowed_packet = 1M table_open_cache = 256 sort_buffer_size = 64M read_buffer_size = 1M read_rnd_buffer_size = 4M myisam_sort_buffer_size = 64M thread_cache_size = 16 thread_concurrency = 24 wait_timeout = 38800 interactive_timeout = 18800 max_delayed_threads = 40 slow_query_log long_query_time = 1 innodb_file_per_table = 1 innodb_buffer_pool_size=5G innodb_additional_mem_pool_size = 256M low_priority_updates = 1 tmp_table_size = 3000M #tmpdir = /tmp/mysql innodb_log_file_size = 256M innodb_flush_log_at_trx_commit=2 max_heap_table_size = 1000M query_cache_limit = 50M
[freebsd] Re: [freebsd] Непонятная активность
а кто вообще висел на 50496? насколько я понял, эта строка обозначает, что соединение уже сдохло. Но какой то ж сервис должен был этот порт открыть 2014-02-23 16:09 GMT+02:00 skeletor : > 22.02.2014 15:31, Andrey пишет: > > Здравствуйте >> >> sockstat -4 >> ?? ? ? tcp4 78.47.ххх.ххх:50496 >> 176.227.195.122:1935 >> >> и таких около 20 штук в выводе. >> >> Это "заразу" подкинули ? >> Как найти и убить? >> >> uname: FreeBSD 10.0-RELEASE #0 r261721 >> >> > Убить можно через tcpdrop. > Касательно знаков вопросов, вот что нашёл в сети: > > The change between 8.2 and 8.3 is that sockstat now also shows > sockets that are not associated with a file descriptor. > Formerly, these were not shown, causing a discrepancy between > sockstat and netstat -a because netstat has always shown them. > > In your case, the sockets on port 2049 are associated with the > kernel NFS client and server. The other TCP sockets are likely > in TIME_WAIT or a similar state. > > Собственно эти соединения и обозначаются знаками вопроса. >
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 21:18 пользователь Eugene Grosbein написал: > On 20.01.2014 02:11, greenh wrote: > > > 1320 cpa 520 215M 33416K accept 13 185:23 64.45% php-fpm > > 1258 cpa 910 215M 33516K CPU99 185:22 63.77% php-fpm > > 1321 cpa 520 215M 33080K accept 8 185:04 63.57% php-fpm > > 1300 cpa 910 215M 33280K CPU44 185:54 63.28% php-fpm > > 1203 cpa 520 215M 33812K accept 12 185:24 62.89% php-fpm > > 1246 cpa 520 215M 33876K accept 3 185:51 62.79% php-fpm > > 1319 cpa 910 215M 33220K CPU33 185:02 62.26% php-fpm > > 1318 cpa 910 215M 41380K CPU11 11 185:18 61.87% php-fpm > > 1322 cpa 910 215M 33352K CPU14 1 185:48 61.77% php-fpm > > Может быть, php-код залили кривой, который стал CPU жрать. > Или атака какая пошла на сервер, перегружающая его работой. > Или и то и другое - код был изначально кривой и кто-то стал его нагружать. > > Да вот не понятно. А как бы посмотреть, что оно делает? может тупит на чем то?
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Странная нагрузка на сервер
2014/1/19 Eugene Grosbein
> On 19.01.2014 23:41, greenh wrote:
>
> > top -s 2 -d 2 36
> >
> > last pid: 9747; load averages: 10.01, 9.89, 10.01 up 0+01:18:11
> 20:32:29
> > 120 processes: 13 running, 106 sleeping, 1 zombie
> >
> > Mem: 1682M Active, 2352M Inact, 2081M Wired, 64K Cache, 2463M Buf, 17G
> Free
> > ARC: 151M Total, 14M MRU, 113M MFU, 560K Anon, 22M Header, 1465K Other
> > Swap: 40G Total, 40G Free
> >
>
> Нет, _вторую_ половину файла. В ней больше данных.
> И я ошибся в аргументах, надо top -SHPI -s 2 -d 2 36
>
> Там не было второй половины )
last pid: 26608; load averages: 6.18, 6.92, 7.40 up 0+03:52:20
23:06:38
469 processes: 30 running, 404 sleeping, 35 waiting
Mem: 1858M Active, 4041M Inact, 2396M Wired, 64K Cache, 2463M Buf, 15G Free
ARC: 374M Total, 7087K MRU, 315M MFU, 496K Anon, 50M Header, 1615K Other
Swap: 40G Total, 40G Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 256K RUN 9 131:27 69.29% idle{idle:
cpu9}
11 root 155 ki31 0K 256K CPU00 117:29 67.29% idle{idle:
cpu0}
11 root 155 ki31 0K 256K RUN10 109:22 65.48% idle{idle:
cpu10}
1320 cpa 910 215M 33416K CPU11 185:21 63.48% php-fpm
1202 cpa 910 215M 33356K CPU15 2 185:49 62.89% php-fpm
1321 cpa 910 215M 33080K CPU99 185:03 62.50% php-fpm
11 root 155 ki31 0K 256K RUN13 99:16 62.50% idle{idle:
cpu13}
1300 cpa 910 215M 33280K CPU66 185:52 62.26% php-fpm
11 root 155 ki31 0K 256K RUN14 100:35 61.96% idle{idle:
cpu14}
1258 cpa 910 215M 33504K CPU11 9 185:20 61.77% php-fpm
1246 cpa 910 215M 33876K CPU14 14 185:50 61.28% php-fpm
11 root 155 ki31 0K 256K CPU33 98:59 60.79% idle{idle:
cpu3}
1203 cpa 910 215M 33812K CPU10 10 185:22 60.69% php-fpm
1322 cpa 910 215M 33352K CPU12 12 185:46 60.25% php-fpm
1318 cpa 520 215M 41380K CPU88 185:17 60.25% php-fpm
1319 cpa 910 215M 33220K CPU44 185:01 60.25% php-fpm
11 root 155 ki31 0K 256K CPU77 97:33 59.77% idle{idle:
cpu7}
11 root 155 ki31 0K 256K RUN 6 104:15 59.47% idle{idle:
cpu6}
11 root 155 ki31 0K 256K RUN 5 98:11 58.98% idle{idle:
cpu5}
11 root 155 ki31 0K 256K RUN12 100:43 58.59% idle{idle:
cpu12}
11 root 155 ki31 0K 256K RUN 2 99:34 57.76% idle{idle:
cpu2}
11 root 155 ki31 0K 256K RUN15 100:14 57.67% idle{idle:
cpu15}
11 root 155 ki31 0K 256K RUN11 94:44 57.18% idle{idle:
cpu11}
11 root 155 ki31 0K 256K RUN 4 100:55 56.69% idle{idle:
cpu4}
11 root 155 ki31 0K 256K RUN 1 88:42 53.66% idle{idle:
cpu1}
11 root 155 ki31 0K 256K RUN 8 82:14 51.27% idle{idle:
cpu8}
12 root -92- 0K 560K WAIT5 18:32 5.86%
intr{irq266: em0:rx 0}
26586 www 280 240M 36112K select 12 0:01 3.66% httpd
1213 www 210 76300K 40836K kqread 15 7:54 2.39% nginx
1215 www 210 64012K 30664K kqread 4 7:51 2.39% nginx
1214 www 210 76300K 40564K kqread 15 7:52 1.86% nginx
26569 www 240 240M 36068K select 8 0:00 1.86% httpd
26508 www 220 240M 36476K select 0 0:00 1.86% httpd
26585 www 270 240M 36060K select 13 0:00 1.66% httpd
1205 mg 200 211M 16960K CPU3 15 4:43 1.37% php-fpm
1204 mg 200 211M 16872K accept 9 4:46 1.17% php-fpm
last pid: 26609; load averages: 6.18, 6.92, 7.40 up 0+03:52:22
23:06:40
469 processes: 26 running, 408 sleeping, 35 waiting
CPU 0: 14.9% user, 0.0% nice, 20.8% system, 0.4% interrupt, 63.9% idle
CPU 1: 24.3% user, 0.0% nice, 31.8% system, 0.0% interrupt, 43.9% idle
CPU 2: 19.6% user, 0.0% nice, 21.6% system, 0.4% interrupt, 58.4% idle
CPU 3: 17.6% user, 0.0% nice, 32.2% system, 0.0% interrupt, 50.2% idle
CPU 4: 19.6% user, 0.0% nice, 29.0% system, 0.0% interrupt, 51.4% idle
CPU 5: 17.7% user, 0.0% nice, 29.9% system, 0.4% interrupt, 52.0% idle
CPU 6: 24.3% user, 0.0% nice, 31.4% system, 0.4% interrupt, 43.9% idle
CPU 7: 20.4% user, 0.0% nice, 21.6% system, 0.0% interrupt, 58.0% idle
CPU 8: 22.0% user, 0.0% nice, 27.1% system, 0.4% interrupt, 50.6% idle
CPU 9: 9.0% user, 0.0% nice, 20.4% system, 6.7% interrupt, 63.9% idle
CPU 10: 16.1% user, 0.0% nice, 28.2% system, 0.0% interrupt, 55.7% idle
CPU 11: 17.6% user, 0.0% nice, 30.6% system, 0.0% interrupt, 51.8% idle
CPU 12: 16.5% user, 0.0% nice, 25.5% system, 0.4% interrupt, 57.6% idle
CPU 13: 21.2% user, 0.0% nice, 27.8% system, 0.4% interrupt, 50.6% idle
CPU 14: 18.8% user, 0.0% nice, 27.8% system, 0.8% in
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 18:37 пользователь Eugene Grosbein написал: > On 19.01.2014 23:33, greenh wrote: > > > Тут интересное не вместилось. Сделай: > > top -s 2 -d 2 $((`sysctl -n kern.smp.cpus`+20)) > top.txt > > > > > > Не совсем понял, что это должно делать? > > В случае sh/bash/zsh оно бы посчитало количество ядер и добавило 20 :-) > > > у меня ругается на > > nw11# top -s 2 -d 2 $((`sysctl -n kern.smp.cpus`+20)) > > Illegal variable name. > > ядер 16, как должна выглядеть команда ? > > top -s 2 -d 2 36 > > last pid: 9747; load averages: 10.01, 9.89, 10.01 up 0+01:18:11 20:32:29 120 processes: 13 running, 106 sleeping, 1 zombie Mem: 1682M Active, 2352M Inact, 2081M Wired, 64K Cache, 2463M Buf, 17G Free ARC: 151M Total, 14M MRU, 113M MFU, 560K Anon, 22M Header, 1465K Other Swap: 40G Total, 40G Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1300 cpa 1 1020 215M 32244K CPU69 65:31 97.46% php-fpm 1246 cpa 1 1020 215M 32688K CPU44 65:31 97.46% php-fpm 1202 cpa 1 1020 215M 32500K CPU55 65:32 97.36% php-fpm 1322 cpa 1 1020 215M 32344K CPU88 65:27 97.36% php-fpm 1320 cpa 1 1020 215M 32012K CPU77 65:15 97.17% php-fpm 1203 cpa 1 1020 215M 32568K CPU10 10 65:20 96.97% php-fpm 1258 cpa 1 1020 215M 32392K CPU13 0 65:19 96.97% php-fpm 1319 cpa 1 520 215M 32296K select 5 65:08 96.78% php-fpm 1318 cpa 1 1020 215M 39500K CPU00 65:16 96.68% php-fpm 1321 cpa 1 1020 215M 32152K CPU11 65:09 96.68% php-fpm 2821 mysql33 200 7060M 1222M uwait 8 10:05 4.69% mysqld 1213 www 1 220 68108K 34756K kqread 3 2:44 4.69% nginx 9728 www 1 240 240M 36196K CPU15 15 0:00 3.76% httpd 9717 www 1 240 240M 36112K select 10 0:01 3.66% httpd 9558 www 1 270 244M 40324K select 1 0:02 3.17% httpd 9719 www 1 230 240M 36044K select 0 0:00 3.17% httpd 1214 www 1 210 76300K 39748K kqread 6 2:46 3.08% nginx 9726 www 1 230 240M 36040K select 7 0:00 2.88% httpd 1215 www 1 210 68108K 34764K kqread 0 2:45 2.49% nginx 1303 mg1 210 211M 16772K accept 14 1:39 2.29% php-fpm 9625 www 1 240 240M 36124K select 8 0:01 2.29% httpd 1205 mg1 210 211M 16960K accept 8 1:44 2.10% php-fpm 1247 mg1 210 211M 16860K accept 12 1:43 2.10% php-fpm 9710 www 1 230 240M 36044K select 15 0:00 1.95% httpd 1259 mg1 210 211M 16728K accept 8 1:45 1.76% php-fpm 1204 mg1 210 211M 16872K accept 7 1:43 1.76% php-fpm 9557 www 1 230 244M 40704K select 11 0:02 1.76% httpd 9731 www 1 220 240M 36040K select 5 0:00 1.76% httpd 9718 www 1 220 240M 35668K select 7 0:00 1.76% httpd 9716 www 1 210 240M 36092K select 0 0:01 1.66% httpd 9611 www 1 220 240M 36112K select 6 0:01 1.56% httpd 9549 www 1 210 240M 36084K select 7 0:00 1.27% httpd 9343 www 1 210 244M 40968K select 14 0:02 1.17% httpd 9559 www 1 210 244M 41060K select 10 0:01 0.98% httpd 9547 www 1 210 244M 40612K select 13 0:02 0.78% httpd
[freebsd] Re: [freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 18:07 пользователь Eugene Grosbein написал: > On 19.01.2014 22:57, greenh wrote: > > 19 января 2014 г., 17:51 пользователь Eugene Grosbein < > eu...@grosbein.net <mailto:eu...@grosbein.net>> написал: > > > > On 19.01.2014 22:23, greenh wrote: > > > Добрый день > > > В какой то момент на сервере неожиданно скаканула нагрзука. top > показывает, что процессы php-fpm отжирают до 100% cpu. При этом по > утверждению разработчиков никто ничего не менял. Возникает устойчивое > ощущение, что он на чем то залипает, хотя винт не занят, в базу тоже вроде > бы нет упора. Как бы посмотреть, чего он тупит? И еще смущает необычайно > высокое system. Подскажите плз, куда смотреть? > > > > > > # uname -a > > > FreeBSD nw11 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Nov 3 > 15:37:14 MSK 2012 root@nw11:/usr/obj/usr/src/sys/GREENH amd64 > > > > > > #top > > > last pid: 51635; load averages: 8.97, 10.15, 10.10 > > up 2+00:37:23 19:10:33 > > > 116 processes: 2 running, 111 sleeping, 2 stopped, 1 zombie > > > CPU: 5.6% user, 0.0% nice, 0.8% system, 0.2% interrupt, 93.3% > idle > > > Mem: 2721M Active, 15G Inact, 5066M Wired, 782M Cache, 2463M Buf, > 188M Free > > > ARC: 2869M Total, 2242K MRU, 2848M MFU, 336K Anon, 17M Header, > 999K Other > > > Swap: 40G Total, 3140K Used, 40G Free > > > > > > PID USERNAMETHR PRI NICE SIZERES STATE C TIME > WCPU COMMAND > > > 3563 mysql37 200 2769M 2132M uwait 5 278:50 > 33.98% mysqld > > > 99102 cpa 1 520 223M 36336K select 12 585:02 > 21.97% php-fpm > > > 99109 cpa 1 520 219M 32636K select 1 429:59 > 21.97% php-fpm > > > 99087 cpa 1 520 223M 34468K select 5 586:16 > 21.88% php-fpm > > > 99100 cpa 1 520 223M 38056K select 14 586:05 > 21.88% php-fpm > > > 99095 cpa 1 520 223M 38360K select 13 586:01 > 21.88% php-fpm > > > 99088 cpa 1 520 223M 38028K select 1 585:37 > 21.88% php-fpm > > > 99108 cpa 1 520 223M 37728K select 12 585:37 > 21.88% php-fpm > > > 99110 cpa 1 520 223M 37656K select 7 584:23 > 21.88% php-fpm > > > 99111 cpa 1 520 223M 37992K select 8 585:27 > 21.78% php-fpm > > > 99113 cpa 1 520 223M 36656K select 1 584:28 > 21.78% php-fpm > > > > А где тут 100% CPU и где "высокое system"? > > > > Покажи top -SHPI в момент высокой загрузки и top -m io - он был снят > в такой момент? > > > > > > top -SHPI > > last pid: 6242; load averages: 10.83, 10.38, 9.43 >up > 0+00:42:20 19:56:38 > > 461 processes: 26 running, 399 sleeping, 1 zombie, 35 waiting > > CPU 0: 19.0% user, 0.0% nice, 47.6% system, 0.0% interrupt, 33.3% idle > > CPU 1: 27.9% user, 0.0% nice, 42.9% system, 0.0% interrupt, 29.3% idle > > CPU 2: 22.4% user, 0.0% nice, 40.1% system, 0.0% interrupt, 37.4% idle > > CPU 3: 18.4% user, 0.0% nice, 46.3% system, 0.7% interrupt, 34.7% idle > > CPU 4: 33.3% user, 0.0% nice, 38.8% system, 0.0% interrupt, 27.9% idle > > CPU 5: 23.8% user, 0.0% nice, 42.9% system, 0.0% interrupt, 33.3% idle > > CPU 6: 22.4% user, 0.0% nice, 39.5% system, 1.4% interrupt, 36.7% idle > > CPU 7: 27.2% user, 0.0% nice, 38.8% system, 0.0% interrupt, 34.0% idle > > CPU 8: 39.5% user, 0.0% nice, 42.9% system, 0.7% interrupt, 17.0% idle > > CPU 9: 15.0% user, 0.0% nice, 22.4% system, 8.2% interrupt, 54.4% idle > > CPU 10: 23.1% user, 0.0% nice, 36.7% system, 0.0% interrupt, 40.1% idle > > CPU 11: 27.9% user, 0.0% nice, 38.8% system, 0.0% interrupt, 33.3% idle > > CPU 12: 22.4% user, 0.0% nice, 38.8% system, 0.0% interrupt, 38.8% idle > > CPU 13: 29.9% user, 0.0% nice, 41.5% system, 0.0% interrupt, 28.6% idle > > CPU 14: 38.1% user, 0.0% nice, 38.1% system, 0.0% interrupt, 23.8% idle > > CPU 15: 17.0% user, 0.0% nice, 38.8% system, 0.7% interrupt, 43.5% idle > > Тут интересное не вместилось. Сделай: > top -s 2 -d 2 $((`sysctl -n kern.smp.cpus`+20)) > top.txt Не совсем понял, что это должно делать? у меня ругается на nw11# top -s 2 -d 2 $((`sysctl -n kern.smp.cpus`+20)) Illegal variable name. ядер 16, как должна выглядеть команда ? >
[freebsd] Re: [freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 18:11 пользователь Eugene Grosbein написал: > On 19.01.2014 22:57, greenh wrote: > > > top -m io был снят в аналогичный момент > > top -m io -o vcsw в студию > > nw11# top -m io -o vcsw last pid: 9323; load averages: 10.88, 10.56, 10.26 up 0+01:14:28 20:28:46 104 processes: 11 running, 92 sleeping, 1 zombie CPU: 23.4% user, 0.0% nice, 38.8% system, 1.1% interrupt, 36.7% idle Mem: 1644M Active, 2067M Inact, 2058M Wired, 64K Cache, 2463M Buf, 18G Free ARC: 145M Total, 14M MRU, 108M MFU, 480K Anon, 21M Header, 1459K Other Swap: 40G Total, 40G Free PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 1320 cpa 14331443 0 0 0 0 0.00% php-fpm 1203 cpa 14309468 0 0 0 0 0.00% php-fpm 1258 cpa 14285508 0 0 0 0 0.00% php-fpm 1321 cpa 14249512 0 0 0 0 0.00% php-fpm 1300 cpa 14145460 0 0 0 0 0.00% php-fpm 1318 cpa 14120410 0 0 0 0 0.00% php-fpm 1202 cpa 14102557 0 0 0 0 0.00% php-fpm 1322 cpa 14052484 0 0 0 0 0.00% php-fpm 1246 cpa 14031489 0 0 0 0 0.00% php-fpm 1319 cpa 13969461 0 0 0 0 0.00% php-fpm 2821 mysql5311 87 46 1102 0 1148 98.37% mysqld 1213 www 2151 16 0 2 0 2 0.17% nginx 1215 www 1826 17 0 0 0 0 0.00% nginx 1214 www 1754 8 0 2 0 2 0.17% nginx 1270 nobody 1158 18 0 0 0 0 0.00% memcached 946 bind 531 5 0 0 0 0 0.00% named 1261 mongodb 421 0 0 0 0 0 0.00% mongod 1204 mg124 20 0 0 0 0 0.00% php-fpm 1247 mg112 6 0 0 0 0 0.00% php-fpm 1259 mg110 6 0 0 0 0 0.00% php-fpm 1205 mg106 6 0 0 0 0 0.00% php-fpm 1303 mg100 13 0 0 0 0 0.00% php-fpm 9025 www75 1 4 0 0 4 0.34% httpd 9217 www66 0 3 0 0 3 0.26% httpd 1967 mysql 61 0 0 8 0 8 0.69% mysqld 9151 www37 8 0 0 0 0 0.00% httpd 1119 zabbix 8 0 0 0 0 0 0.00% zabbix_agentd 1120 zabbix 7 0 0 0 0 0 0.00% zabbix_agentd 9247 www 7 0 0 0 0 0 0.00% httpd 1983 root6 0 0 0 0 0 0.00% httpd 1201 root5 0 0 0 0 0 0.00% php-fpm 1118 zabbix 5 0 0 0 0 0 0.00% zabbix_agentd 9268 www 2 0 0 0 0 0 0.00% httpd 1193 _sphinx 2 0 0 0 0 0 0.00% searchd 1121 zabbix 2 0 0 0 0 0 0.00% zabbix_agentd
[freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 17:51 пользователь Eugene Grosbein написал: > On 19.01.2014 22:23, greenh wrote: > > Добрый день > > В какой то момент на сервере неожиданно скаканула нагрзука. top > показывает, что процессы php-fpm отжирают до 100% cpu. При этом по > утверждению разработчиков никто ничего не менял. Возникает устойчивое > ощущение, что он на чем то залипает, хотя винт не занят, в базу тоже вроде > бы нет упора. Как бы посмотреть, чего он тупит? И еще смущает необычайно > высокое system. Подскажите плз, куда смотреть? > > > > # uname -a > > FreeBSD nw11 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Nov 3 > 15:37:14 MSK 2012 root@nw11:/usr/obj/usr/src/sys/GREENH amd64 > > > > #top > > last pid: 51635; load averages: 8.97, 10.15, 10.10 >up > 2+00:37:23 19:10:33 > > 116 processes: 2 running, 111 sleeping, 2 stopped, 1 zombie > > CPU: 5.6% user, 0.0% nice, 0.8% system, 0.2% interrupt, 93.3% idle > > Mem: 2721M Active, 15G Inact, 5066M Wired, 782M Cache, 2463M Buf, 188M > Free > > ARC: 2869M Total, 2242K MRU, 2848M MFU, 336K Anon, 17M Header, 999K Other > > Swap: 40G Total, 3140K Used, 40G Free > > > > PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU > COMMAND > > 3563 mysql37 200 2769M 2132M uwait 5 278:50 33.98% > mysqld > > 99102 cpa 1 520 223M 36336K select 12 585:02 21.97% > php-fpm > > 99109 cpa 1 520 219M 32636K select 1 429:59 21.97% > php-fpm > > 99087 cpa 1 520 223M 34468K select 5 586:16 21.88% > php-fpm > > 99100 cpa 1 520 223M 38056K select 14 586:05 21.88% > php-fpm > > 99095 cpa 1 520 223M 38360K select 13 586:01 21.88% > php-fpm > > 99088 cpa 1 520 223M 38028K select 1 585:37 21.88% > php-fpm > > 99108 cpa 1 520 223M 37728K select 12 585:37 21.88% > php-fpm > > 99110 cpa 1 520 223M 37656K select 7 584:23 21.88% > php-fpm > > 99111 cpa 1 520 223M 37992K select 8 585:27 21.78% > php-fpm > > 99113 cpa 1 520 223M 36656K select 1 584:28 21.78% > php-fpm > > А где тут 100% CPU и где "высокое system"? > > Покажи top -SHPI в момент высокой загрузки и top -m io - он был снят в > такой момент? > > > top -SHPI last pid: 6242; load averages: 10.83, 10.38, 9.43 up 0+00:42:20 19:56:38 461 processes: 26 running, 399 sleeping, 1 zombie, 35 waiting CPU 0: 19.0% user, 0.0% nice, 47.6% system, 0.0% interrupt, 33.3% idle CPU 1: 27.9% user, 0.0% nice, 42.9% system, 0.0% interrupt, 29.3% idle CPU 2: 22.4% user, 0.0% nice, 40.1% system, 0.0% interrupt, 37.4% idle CPU 3: 18.4% user, 0.0% nice, 46.3% system, 0.7% interrupt, 34.7% idle CPU 4: 33.3% user, 0.0% nice, 38.8% system, 0.0% interrupt, 27.9% idle CPU 5: 23.8% user, 0.0% nice, 42.9% system, 0.0% interrupt, 33.3% idle CPU 6: 22.4% user, 0.0% nice, 39.5% system, 1.4% interrupt, 36.7% idle CPU 7: 27.2% user, 0.0% nice, 38.8% system, 0.0% interrupt, 34.0% idle CPU 8: 39.5% user, 0.0% nice, 42.9% system, 0.7% interrupt, 17.0% idle CPU 9: 15.0% user, 0.0% nice, 22.4% system, 8.2% interrupt, 54.4% idle CPU 10: 23.1% user, 0.0% nice, 36.7% system, 0.0% interrupt, 40.1% idle CPU 11: 27.9% user, 0.0% nice, 38.8% system, 0.0% interrupt, 33.3% idle CPU 12: 22.4% user, 0.0% nice, 38.8% system, 0.0% interrupt, 38.8% idle CPU 13: 29.9% user, 0.0% nice, 41.5% system, 0.0% interrupt, 28.6% idle CPU 14: 38.1% user, 0.0% nice, 38.1% system, 0.0% interrupt, 23.8% idle CPU 15: 17.0% user, 0.0% nice, 38.8% system, 0.7% interrupt, 43.5% idle Mem: 1468M Active, 1587M Inact, 1936M Wired, 64K Cache, 2463M Buf, 18G Free ARC: 91M Total, 15M MRU, 60M MFU, 544K Anon, 15M Header, 1454K Other Swap: 40G Total, 40G Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 1202 cpa 520 215M 32284K CPU88 33:22 100.00% php-fpm 1246 cpa 520 215M 32624K CPU11 4 33:21 100.00% php-fpm 1300 cpa1010 215M 27952K CPU00 33:20 100.00% php-fpm 1322 cpa1020 215M 27644K CPU14 14 33:17 100.00% php-fpm 1203 cpa1010 215M 32324K CPU12 12 33:15 100.00% php-fpm 1258 cpa1020 215M 31592K CPU77 33:14 100.00% php-fpm 1318 cpa1020 215M 31256K CPU55 33:13 100.00% php-fpm 1320 cpa1010 211M 26636K CPU99 33:10 100.00% php-fpm 1321 cpa 520 215M 31568K select 5 33:08 100.00% php-fpm 1319 cpa1020 215M 32164K CPU13 13 33:06 100.00% php-fpm top -m io был снят в аналогичный момент
[freebsd] Re: [freebsd] Странная нагрузка на сервер
19 января 2014 г., 17:36 пользователь Eugene Grosbein написал: > On 19.01.2014 22:23, greenh wrote: > > Добрый день > > В какой то момент на сервере неожиданно скаканула нагрзука. top > показывает, что процессы php-fpm отжирают до 100% cpu. При этом по > утверждению разработчиков никто ничего не менял. Возникает устойчивое > ощущение, что он на чем то залипает, хотя винт не занят, в базу тоже вроде > бы нет упора. Как бы посмотреть, чего он тупит? И еще смущает необычайно > высокое system. Подскажите плз, куда смотреть? > > > > # uname -a > > FreeBSD nw11 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Nov 3 > 15:37:14 MSK 2012 root@nw11:/usr/obj/usr/src/sys/GREENH amd64 > > > > #top > > last pid: 51635; load averages: 8.97, 10.15, 10.10 >up > 2+00:37:23 19:10:33 > > 116 processes: 2 running, 111 sleeping, 2 stopped, 1 zombie > > CPU: 5.6% user, 0.0% nice, 0.8% system, 0.2% interrupt, 93.3% idle > > Mem: 2721M Active, 15G Inact, 5066M Wired, 782M Cache, 2463M Buf, 188M > Free > > ARC: 2869M Total, 2242K MRU, 2848M MFU, 336K Anon, 17M Header, 999K Other > > Swap: 40G Total, 3140K Used, 40G Free > > > > PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU > COMMAND > > 3563 mysql37 200 2769M 2132M uwait 5 278:50 33.98% > mysqld > > 99102 cpa 1 520 223M 36336K select 12 585:02 21.97% > php-fpm > > 99109 cpa 1 520 219M 32636K select 1 429:59 21.97% > php-fpm > > 99087 cpa 1 520 223M 34468K select 5 586:16 21.88% > php-fpm > > 99100 cpa 1 520 223M 38056K select 14 586:05 21.88% > php-fpm > > 99095 cpa 1 520 223M 38360K select 13 586:01 21.88% > php-fpm > > 99088 cpa 1 520 223M 38028K select 1 585:37 21.88% > php-fpm > > 99108 cpa 1 520 223M 37728K select 12 585:37 21.88% > php-fpm > > 99110 cpa 1 520 223M 37656K select 7 584:23 21.88% > php-fpm > > 99111 cpa 1 520 223M 37992K select 8 585:27 21.78% > php-fpm > > 99113 cpa 1 520 223M 36656K select 1 584:28 21.78% > php-fpm > > Начнем с традиционного. UFS или ZFS? Покажи вывод sysctl vfs.ufs, > а также top -io. > > ZFS nw11# sysctl vfs.ufs vfs.ufs.dirhash_reclaimage: 5 vfs.ufs.dirhash_lowmemcount: 0 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 5696206 vfs.ufs.dirhash_maxmem: 40349696 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.rename_restarts: 0 nw11# top -m io last pid: 4716; load averages: 9.70, 9.63, 7.79 up 0+00:27:51 19:42:09 119 processes: 11 running, 108 sleeping CPU: 24.0% user, 0.0% nice, 40.9% system, 1.2% interrupt, 33.9% idle Mem: 1356M Active, 1217M Inact, 1842M Wired, 64K Cache, 2463M Buf, 19G Free ARC: 69M Total, 15M MRU, 41M MFU, 496K Anon, 11M Header, 1451K Other Swap: 40G Total, 40G Free PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 1202 cpa 14496455 0 0 0 0 0.00% php-fpm 1246 cpa 14335540 0 0 0 0 0.00% php-fpm 1300 cpa 14353480 0 0 0 0 0.00% php-fpm 1203 cpa 14374487 0 0 0 0 0.00% php-fpm 1322 cpa 14588511 0 0 0 0 0.00% php-fpm 1318 cpa 14840500 0 0 0 0 0.00% php-fpm 1320 cpa 14728549 0 0 0 0 0.00% php-fpm 1321 cpa 14153538 0 0 0 0 0.00% php-fpm 1319 cpa 14405493 0 0 0 0 0.00% php-fpm 1258 cpa 14312492 0 0 0 0 0.00% php-fpm 2821 mysql5167 93 34 1100 0 1134 98.27% mysqld 4490 www 0 0 0 0 0 0 0.00% httpd 1215 www 2182 29 0 2 0 2 0.17% nginx 1214 www 1585 15 0 2 0 2 0.17% nginx 1213 www 1741 17 0 0 0 0 0.00% nginx 4642 www 0 0 0 0 0 0 0.00% httpd 4646 www10 0 0 1 0 1 0.09% httpd 4598 www 0 0 0 0 0 0 0.00% httpd как бы ничего интересного вроде и нет
[freebsd] Странная нагрузка на сервер
Добрый день В какой то момент на сервере неожиданно скаканула нагрзука. top показывает, что процессы php-fpm отжирают до 100% cpu. При этом по утверждению разработчиков никто ничего не менял. Возникает устойчивое ощущение, что он на чем то залипает, хотя винт не занят, в базу тоже вроде бы нет упора. Как бы посмотреть, чего он тупит? И еще смущает необычайно высокое system. Подскажите плз, куда смотреть? # uname -a FreeBSD nw11 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Nov 3 15:37:14 MSK 2012 root@nw11:/usr/obj/usr/src/sys/GREENH amd64 #top last pid: 51635; load averages: 8.97, 10.15, 10.10 up 2+00:37:23 19:10:33 116 processes: 2 running, 111 sleeping, 2 stopped, 1 zombie CPU: 5.6% user, 0.0% nice, 0.8% system, 0.2% interrupt, 93.3% idle Mem: 2721M Active, 15G Inact, 5066M Wired, 782M Cache, 2463M Buf, 188M Free ARC: 2869M Total, 2242K MRU, 2848M MFU, 336K Anon, 17M Header, 999K Other Swap: 40G Total, 3140K Used, 40G Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 3563 mysql37 200 2769M 2132M uwait 5 278:50 33.98% mysqld 99102 cpa 1 520 223M 36336K select 12 585:02 21.97% php-fpm 99109 cpa 1 520 219M 32636K select 1 429:59 21.97% php-fpm 99087 cpa 1 520 223M 34468K select 5 586:16 21.88% php-fpm 99100 cpa 1 520 223M 38056K select 14 586:05 21.88% php-fpm 99095 cpa 1 520 223M 38360K select 13 586:01 21.88% php-fpm 99088 cpa 1 520 223M 38028K select 1 585:37 21.88% php-fpm 99108 cpa 1 520 223M 37728K select 12 585:37 21.88% php-fpm 99110 cpa 1 520 223M 37656K select 7 584:23 21.88% php-fpm 99111 cpa 1 520 223M 37992K select 8 585:27 21.78% php-fpm 99113 cpa 1 520 223M 36656K select 1 584:28 21.78% php-fpm # netstat -m 3157/5168/8325 mbufs in use (current/cache/total) 2582/4204/6786/200 mbuf clusters in use (current/cache/total/max) 2582/3050 mbuf+clusters out of packet secondary zone in use (current/cache) 90/606/696/528000 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 6313K/12124K/18437K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 182 requests for I/O initiated by sendfile 0 calls to protocol drain routines
Re: [freebsd] net.inet.ip.random_id=1
25 декабря 2013 г., 16:47 пользователь Eugene Grosbein написал: > On 25.12.2013 21:39, skele...@lissyara.su wrote: > > Всем привет. > > Насколько оправдано использование этой опции? Не вызывает ли это > > увеличение нагрузки на CPU (или на другое влияет, например, снижение > > пропускной способности) при большом потоке трафика? > > Ведь для каждого пакета приходиться генерировать новый random ID. > > Не очень часто встречаются машины, в которых CPU занят на 100%, > так что генерация random id напрягала. А у тех, что занят на 100%, > вовсе не генерация random id основное узкое место. > Если не секрет - в чем высший смысл net.inet.ip.random_id?
[freebsd] Re: [freebsd] Re: Собрать порт, который конфликтует с уже установленным
24 декабря 2013 г., 17:22 пользователь skele...@lissyara.su < skele...@lissyara.su> написал: > 24.12.2013 17:13, Alexander Yerenkow пишет: > >> >> >> >> 24 декабря 2013 г., 17:08 пользователь Anton Sayetsky > <mailto:vsj...@gmail.com>> написал: >> >> >> 24 декабря 2013 г., 16:46 пользователь greenh > <mailto:gre...@gmail.com>> написал: >> >> > Репикацию нельзя считать бекапом. >> >> >> Если репликация консистентная и более-менее умная, то это хорошее >> приближение. >> >> stop slave; >> mysqldump | zfs send | etc >> start slave; >> >> >> Простой мастера может быть дорог или неприемлим. А бекап репликации, >> перефразирую по вашему, бекап "не бекапа" это вообще что будет? )) >> Но да, это тоже хорошее приближение. >> >> >> >> -- >> Regards, >> Alexander Yerenkow >> > > > Давайте не будем уходить от темы :) > Отвечу на ваши вопросы. На сервере с 7.4 нет zfs пулов, а даже если бы и > были, то не факт, что они приняли бы нормально снапшоты с Solaris 11.1, у > которых версии zfs/zpool очень сильно отличаются. > Если бы можно было пересетапить (или нормально обновить до 8-9) 7.4, то > давно бы уже это сделал. > а переставить систему с нуля совсем не реально?
[freebsd] Re: [freebsd] Re: Собрать порт, который конфликтует с уже установленным
23 декабря 2013 г., 17:24 пользователь skele...@lissyara.su < skele...@lissyara.su> написал: > 23.12.2013 17:04, Anton Sayetsky пишет: > > Это всё хорошо, конечно... Но вот никак я не пойму одного - что мешает >> ТС просто сделать mysqldump -h oldserver -a -p | mysql -h newserver -p >> >> > Если бы так всё просто было - не писал бы сюда. > Он же написал - сотни гиг. процесс на несколько суток. А вот стопнуть мускул, скопиролвать ФАЙЛЫ баз и запустить - вполне метод бекапа. для таких ситуаций. или снапшот. Кста, а как вы вообще бекапите сотни гиг баз?
Re: [freebsd] dns amplification attack
10 декабря 2013 г., 12:29 пользователь Anton Yuzhaninov написал: > On 12/10/13 14:17, greenh wrote: > >> >> У меня свои зоны. По идее рекурсию можно отключать и это решит вопросы? >> > > В данномслучае да, прикрытия рекурсии через ACL хватит. (если > packetdevil.com это не ваш домена, а он похоже не ваш). > > Но authoritative DNS тоже могут использоваться для подобных аттак, хоть и > менее эффективно. И тут поможет Response Rate Limiting, который есть в NSD > и bind10 > В приведенном логе вообще нет наших зон. я их вырезал, для наглядности
Re: [freebsd] dns amplification attack
10 декабря 2013 г., 12:11 пользователь Anton Yuzhaninov
написал:
> On 12/10/13 14:05, greenh wrote:
>
>> Господа, подскажите плз, как с этой дрянью бороться
>> мне тут хостер намекнул, что мои ДНС сервера для этого используют, и
>> tcpdump
>> намекает, что они похоже правы
>>
>> Как с этим можно бороться? Гугление что то не дало вменяемых результатов.
>>
>> # tcpdump -i em1 port 53
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 14:01:10.112093 IP n11212086169.netvigator.com.41033 >
>> 92.241.171.233.domain:
>> 37722+ [1au] A? a.packetdevil.com <http://a.packetdevil.com>. (46)
>>
>
> У вас открта рекурсия для всех? Откройте только для localhost и сетей в
> которых живут другие ваши сервера (если такие есть).
>
> Если у вас bind, то что то вроде
>
> acl "mynet" {
> 127.0.0.0/8;
> 10.0.0.0/8;
> };
>
> options {
>...
>allow-recursion { mynet; };
>...
> }
>
> Если своих зон на этом сервере нет, то и
> allow-query { mynet; };
>
> Если же есть свои зоны, то лучше перенести их на nsd (и настроить там rate
> limit).
>
У меня свои зоны. По идее рекурсию можно отключать и это решит вопросы?
[freebsd] dns amplification attack
Господа, подскажите плз, как с этой дрянью бороться мне тут хостер намекнул, что мои ДНС сервера для этого используют, и tcpdump намекает, что они похоже правы Как с этим можно бороться? Гугление что то не дало вменяемых результатов. # tcpdump -i em1 port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:01:10.112093 IP n11212086169.netvigator.com.41033 > 92.241.171.233.domain: 37722+ [1au] A? a.packetdevil.com. (46) 14:01:10.112377 IP 92.241.171.233.domain > n11212086169.netvigator.com.41033: 37722 252/1/1 A 204.11.52.245, A 204.11.52.246, A 204.11.52.247, A 204.11.52.248, A 204.11.52.249, A 204.11.52.250, A 204.11.52.251, A 204.11.52.252, A 204.11.52.253, A 204.11.52.254, A 204.11.52.255, A 204.11.53.0, A 204.11.53.1, A 204.11.53.2, A 204.11.53.3, A 204.11.53.4, A 204.11.53.5, A 204.11.53.6, A 204.11.53.7, A 204.11.53.8, A 204.11.53.9, A 204.11.53.10, A 204.11.53.11, A 204.11.53.12, A 204.11.53.13, A 204.11.53.14, A 204.11.53.15, A 204.11.53.16, A 204.11.53.17, A 204.11.53.18, A 204.11.53.19, A 204.11.53.20, A 204.11.53.21, A 204.11.53.22, A 204.11.53.23, A 204.11.53.24, A 204.11.53.25, A 204.11.53.26, A 204.11.53.27, A 204.11.53.28, A 204.11.53.29, A 204.11.53.30, A 204.11.53.31, A 204.11.53.32, A 204.11.53.33, A 204.11.53.34, A 204.11.53.35, A 204.11.53.36, A 204.11.53.37, A 204.11.53.38, A 204.11.53.39, A 204.11.53.40, A 204.11.53.41, A 204.11.53.42, A 204.11.53.43, A 204.11.53.44, A 204.11.53.45, A 204.11.53.46, A 204.11.53.47, A 204.11.53.48, A 204.11.53.49, A 204.11.53.50, A 204.11.53.51, A 204.11.53.52, A 204.11.53.53, A 204.11.53.54, A 204.11.53.55, A 204.11.53.56, A 204.11.53.57, A 204.11.53.58, A 204.11.53.59, A 204.11.53.60, A 204.11.53.61, A 204.11.53.62, A 204.11.53.63, A 204.11.53.64, A 204.11.53.65, A 204.11.53.66, A 204.11.53.67, A 204.11.53.68, A 204.11.53.69, A 204.11.53.70, A 204.11.53.71, A 204.11.53.72, A 204.11.53.73, A 204.11.53.74, A 204.11.53.75, A 204.11.53.76, A 204.11.53.77, A[|domain] 14:01:10.119675 IP 92.241.171.233.domain > 180.168.255.12.51541: 61364* 1/4/4 A 92.241.171.233 (181) 14:01:10.131028 IP n11212086169.netvigator.com.50104 > 92.241.171.233.domain: 4663+ [1au] A? a.packetdevil.com. (46) 14:01:10.131261 IP 92.241.171.233.domain > n11212086169.netvigator.com.50104: 4663 252/1/1 A 204.11.52.246, A 204.11.52.247, A 204.11.52.248, A 204.11.52.249, A 204.11.52.250, A 204.11.52.251, A 204.11.52.252, A 204.11.52.253, A 204.11.52.254, A 204.11.52.255, A 204.11.53.0, A 204.11.53.1, A 204.11.53.2, A 204.11.53.3, A 204.11.53.4, A 204.11.53.5, A 204.11.53.6, A 204.11.53.7, A 204.11.53.8, A 204.11.53.9, A 204.11.53.10, A 204.11.53.11, A 204.11.53.12, A 204.11.53.13, A 204.11.53.14, A 204.11.53.15, A 204.11.53.16, A 204.11.53.17, A 204.11.53.18, A 204.11.53.19, A 204.11.53.20, A 204.11.53.21, A 204.11.53.22, A 204.11.53.23, A 204.11.53.24, A 204.11.53.25, A 204.11.53.26, A 204.11.53.27, A 204.11.53.28, A 204.11.53.29, A 204.11.53.30, A 204.11.53.31, A 204.11.53.32, A 204.11.53.33, A 204.11.53.34, A 204.11.53.35, A 204.11.53.36, A 204.11.53.37, A 204.11.53.38, A 204.11.53.39, A 204.11.53.40, A 204.11.53.41, A 204.11.53.42, A 204.11.53.43, A 204.11.53.44, A 204.11.53.45, A 204.11.53.46, A 204.11.53.47, A 204.11.53.48, A 204.11.53.49, A 204.11.53.50, A 204.11.53.51, A 204.11.53.52, A 204.11.53.53, A 204.11.53.54, A 204.11.53.55, A 204.11.53.56, A 204.11.53.57, A 204.11.53.58, A 204.11.53.59, A 204.11.53.60, A 204.11.53.61, A 204.11.53.62, A 204.11.53.63, A 204.11.53.64, A 204.11.53.65, A 204.11.53.66, A 204.11.53.67, A 204.11.53.68, A 204.11.53.69, A 204.11.53.70, A 204.11.53.71, A 204.11.53.72, A 204.11.53.73, A 204.11.53.74, A 204.11.53.75, A 204.11.53.76, A 204.11.53.77, A 204.11.53.78, A[|domain]
[freebsd] Re: [freebsd] RE: freebsd 9.2 проверить файловую систему
28 ноября 2013 г., 10:55 пользователь Eugene Grosbein написал: > On 28.11.2013 15:12, alexander.druz...@raz.ru wrote: > > >> root@kiwi:/usr/home/lx # mount > >> /dev/da0p2 on / (ufs, local, journaled soft-updates) > >> devfs on /dev (devfs, local, multilabel) > >> /dev/da0p4 on /u (ufs, local, journaled soft-updates) > >> devfs on /var/named/dev (devfs, local, multilabel) > > > > Наверное слишком тупой вопрос. > > Ну хорошо, а как народ относится к fsck_y_enable="YES" в rc.conf? > > Хорошо, надо всегда ставить. > > > И заодно, что насчёт background_fsck="NO"? > > Пишут, что "YES", который по умолчанию, может приводить к нежелательным > последствиям. > > IMHO, backgroupd_fsck не актуален для journaled soft-updates. > Оно для не journaled. > Сорри, а почему?
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] ZABBIX и перерывы в графиках
А что с заббксом то делать? 23 ноября 2013 г., 14:53 пользователь Anton Sayetsky написал: > 23 ноября 2013 г., 11:32 пользователь Sergey Rudenko > написал: > > Что касаемо кактуса. У нас он обрабатывает около сотни девайсов (в > основном > > свичи) на около 1000 графиков. > ... > > Поллер стандартный пхпшный(где-то видел Сишный делали), тазик > > - двуядерник, не самый быстрый > Настоятельно рекомендую поставить нормальный, сишный поллер. ПХПшный > жестоко тупит, работает в несколько раз медленнее. >
[freebsd] Re: [freebsd] ZABBIX и перерывы в графиках
Мускул в порядке, не упирается ни во что 22 ноября 2013 г., 17:37 пользователь Vladislav V. Prodan < ad...@support.od.ua> написал: > Крутите настройки Mysql. > У меня похожая беда, но с cacti. > Планирую мигрировать на SSD диски. > Посоветуете, какие брать? > > > 22 ноября 2013 г., 17:11 пользователь greenh написал: > > Добрый день >> Дамы и господа, подскажите плз, как с этим бороться >> На графиках заббикса начали в больших количествах появляться разрывы. >> Посчитали, что слаб серв (амазоновский инстанс) и переехали на железный >> тазик, за одно и обновив заббикс до 2.2 >> Ситуация улучшилась, но не до идеала >> пример >> http://hostingkartinok.com/show-image.php?id=071530483c895fc43a586db80766d32e >> ЧТо это может быть и как фиксить? Мониторится чуть более 25 хостов >> > > > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE >
[freebsd] ZABBIX и перерывы в графиках
Добрый день Дамы и господа, подскажите плз, как с этим бороться На графиках заббикса начали в больших количествах появляться разрывы. Посчитали, что слаб серв (амазоновский инстанс) и переехали на железный тазик, за одно и обновив заббикс до 2.2 Ситуация улучшилась, но не до идеала пример http://hostingkartinok.com/show-image.php?id=071530483c895fc43a586db80766d32e ЧТо это может быть и как фиксить? Мониторится чуть более 25 хостов
[freebsd] Re: Как узнать размер папки
СОрри, уже выяснили Компрессия правда неожиданно, что в три раза.. 14 ноября 2013 г., 16:14 пользователь greenh написал: > Имеется папка с базой > пытаюсь узнать размер и чего то не понимаю > # ls -lhS > total 24945824 > -rw-rw 1 mysql mysql 7.8G Nov 11 01:00 > statistic_download_20131110.ibd > -rw-rw 1 mysql mysql 7.5G Nov 13 01:00 > statistic_download_20131112.ibd > -rw-rw 1 mysql mysql 7.1G Nov 10 00:56 > statistic_download_20131109.ibd > -rw-rw 1 mysql mysql 7G Nov 12 01:00 > statistic_download_2013.ibd > -rw-rw 1 mysql mysql 6.9G Nov 14 01:01 > statistic_download_20131113.ibd > -rw-rw 1 mysql mysql 6.8G Nov 9 00:59 > statistic_download_20131108.ibd > -rw-rw 1 mysql mysql 6.8G Nov 6 01:03 > statistic_download_20131105.ibd > -rw-rw 1 mysql mysql 6.8G Nov 8 00:59 > statistic_download_20131107.ibd > -rw-rw 1 mysql mysql 6.4G Nov 7 01:00 > statistic_download_20131106.ibd > -rw-rw 1 mysql mysql 4.1G Nov 14 18:11 > statistic_download_20131114.ibd > -rw-rw 1 mysql mysql 1.6G Nov 14 18:11 total_download.ibd > > но при этом в ней же > # du -h > 23G. > > Это как понимать? > Zfs, freebsd 9.1 >
[freebsd] Как узнать размер папки
Имеется папка с базой пытаюсь узнать размер и чего то не понимаю # ls -lhS total 24945824 -rw-rw 1 mysql mysql 7.8G Nov 11 01:00 statistic_download_20131110.ibd -rw-rw 1 mysql mysql 7.5G Nov 13 01:00 statistic_download_20131112.ibd -rw-rw 1 mysql mysql 7.1G Nov 10 00:56 statistic_download_20131109.ibd -rw-rw 1 mysql mysql 7G Nov 12 01:00 statistic_download_2013.ibd -rw-rw 1 mysql mysql 6.9G Nov 14 01:01 statistic_download_20131113.ibd -rw-rw 1 mysql mysql 6.8G Nov 9 00:59 statistic_download_20131108.ibd -rw-rw 1 mysql mysql 6.8G Nov 6 01:03 statistic_download_20131105.ibd -rw-rw 1 mysql mysql 6.8G Nov 8 00:59 statistic_download_20131107.ibd -rw-rw 1 mysql mysql 6.4G Nov 7 01:00 statistic_download_20131106.ibd -rw-rw 1 mysql mysql 4.1G Nov 14 18:11 statistic_download_20131114.ibd -rw-rw 1 mysql mysql 1.6G Nov 14 18:11 total_download.ibd но при этом в ней же # du -h 23G. Это как понимать? Zfs, freebsd 9.1
[freebsd] Re: [freebsd] youtube, Firefox и Flash
Да пусть хоть отсыпят... PS> кажется ща кто то попадет в бан 2013/11/3 Sergey Kobzar > On 11/02/13 23:01, Slawa Olhovchenkov wrote: > >> On Sat, Nov 02, 2013 at 10:45:59PM +0200, George L. Yermulnik wrote: >> >> Hello! >>> >>> On Sat, 02 Nov 2013 at 23:35:54 (+0400), Slawa Olhovchenkov wrote: >>> >>> УМНВР >>> >>> А разве не "УМВРН"? >>> >> >> УМВРЧЯНТ >> > > Мужики, дайте курнуть! :) >
[freebsd] Re: [freebsd] youtube, Firefox и Flash
Я правильно понимаю, что флеш на фре не будет жить никогда? 1 ноября 2013 г., 23:40 пользователь написал: > > > А например какие ролики с youtube не проигрываются? > > > Например, http://www.youtube.com/watch?v=8bVAl73JvLM > > У меня сейчас показывает, во всех разрешениях, fullscreen и без. > dom.ipc.plugins.enabled.npwrapper.libflashplayer.so - true > dom.ipc.plugins.enabled - true > 8.4-RELEASE-p4 i386 > firefox-25.0,1gcc-4.6.3_1 > linux-f10-flashplugin-11.2r202.310 nspluginwrapper-1.4.4_1 > обычные иксы (не new), без hal, без composite > nvidia-driver-304.88_1 GeForce 6150/integrated > >
Re: [freebsd] RAID LSI 2108 vs Adaptec 6405(T)
адаптеков штук 15 разных, lsi - 2 штуки, из которых одну вернули и заменили на адаптек 31 октября 2013 г., 10:23 пользователь Alexander Yerenkow < yeren...@gmail.com> написал: > > > > 31 октября 2013 г., 10:14 пользователь greenh написал: > > >> >> >>> >>> Adaptec, из известных брендов, пожалуй, худший. >>> >> Боюсь, вынужден буду с Вами не согласится. Мой опыт использования >> адаптека всегда был положителен - поставил и забыл. >> > > Напишите уж тогда для истории примерное количество ваших использований > адаптек рейдов :) > > >> При попытке перейти на LSI вечно были какие нить приколы >> > И тут тоже, интересно о каком объеме проблем идёт речь - разовые грабли с > конкретными моделями, или же массово-часто. > > >> >>> Для ZFS аппаратный RAID не нужен, даже мешать будет. >>> >>> >> > > > -- > Regards, > Alexander Yerenkow >
Re: [freebsd] RAID LSI 2108 vs Adaptec 6405(T)
30 октября 2013 г., 16:46 пользователь Владимир Друзенко написал: > 30.10.2013 18:36, Алексей Бобок пишет: > > Приветствую! > Вопрос больше даже по железу. > > Планируем закупить сервер > http://www.supermicro.com/products/system/4u/6047/ssg-6047r-e1r36n.cfm > Хотим поставить RAID-контроллер > http://www.adaptec.com/ru-ru/products/series/6-6t/ > На нем необходимо > 1) базово создать 1 массива: > - Из 4 х SATA > - Из 4 х SAS > 2) все остальные SATA-диски "пробросить" в ОС, чтобы из них сделать > ZFS-пул. Диски по мере роста будем доставлять в сервер и расширять пул. > > Интегратор гнет линию, что лучше родной onboard LSI-контроллер, что > бекплейн "не факт что будет корректно работать с контроллером другого > производителя", диски будут случайно "отваливаться и приваливаться". > > Как Вы считаете? > Так же есть ли опыт работы с указанными контроллерами? > > -- > Think before you print. > Best regards, Alexey Bobok. > > > Adaptec, из известных брендов, пожалуй, худший. > Боюсь, вынужден буду с Вами не согласится. Мой опыт использования адаптека всегда был положителен - поставил и забыл. При попытке перейти на LSI вечно были какие нить приколы > > Для ZFS аппаратный RAID не нужен, даже мешать будет. > >
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] mc и scp на zfs
30 октября 2013 г., 10:59 пользователь Anton Sayetsky написал: > 30 октября 2013 г., 8:57 пользователь Sergey V. Dyatko > написал: > > согласен, именно с этим валится > > [tiger@laptop]:/<2>misc/mc%svn info |grep -i ^rev > > Revision: 331932 > > > > ну.. тогда ставить из репо и не париться? либо откатывать коммит > > и ставить;-) > Если сильно нужно собрать mc сейчас - то лучше откатить > Mk/bsd.options.mk на 1 ревизию назад, собрать и вернуть обратно. Сорри, а это как? > Потом > дождаться человеческого фикса миднайта. Я там, кстати, вообще не вижу > LIB_DEPENDS для SMB. >
[freebsd] mc и scp на zfs
В последнее время начал массовый переход серверов на zfs и заметил странную вещь: при копировании файлов по scp через mc такое ощущение, что идут какие то глюки перерисовки, и остаются следы предыдущих имен файлов. Что бы это могло быть?
[freebsd] Re: [freebsd] Новый матюк в dmesg
17 октября 2013 г., 11:49 пользователь Anton Yuzhaninov написал: > On 10/16/13 20:29, greenh wrote: > >> Господа, подскажите плз, что это может быть за матюк: sonewconn: pcb >> 0xfe0404548690: Listen queue overflow: 151 already in queue awaiting >> acceptance >> > > А что показыват netstat -Lan под нагрузкой и какая длинная очереди? > На современных серверах kern.ipc.somaxconn имеет смысл увеличивать до 4096 > > > # netstat -Lan Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/511127.0.0.3.80 tcp4 0/0/128*.22 tcp4 0/0/50 *.3306 tcp4 0/0/60096 *.80 tcp46 0/0/100*.3306 tcp4 0/0/60096 *.21 tcp4 0/0/10 127.0.0.1.25 tcp4 0/0/128*.22468 tcp6 0/0/128*.22468 tcp4 0/0/60096 *.80 Some tcp sockets may have been created. unix 0/0/50 /tmp/mysql.sock unix 0/0/100/tmp/mysql.sock unix 0/0/60096 /home/mt/run/socket unix 0/0/60096 /home/client/run/socket2 unix 0/0/60096 /home/client/run/socket unix 0/0/4 /var/run/devd.pipe > Перенес проект с довольно большой нагрузкой на новый сервак с 9.2 и >> увидел такое >> в dmesg. При этом мускул ругается на too many connectiion. Настройки >> sysctl >> скопированы 1 в 1 >> > > И настройки mysql тоже? > да, конечно > А график с числом активных подключений к mysql в мониторинге рисуется? На > нем нет сильных изменений? > Увы, график не строил (
[freebsd] Re: [freebsd] Новый матюк в dmesg
17 октября 2013 г., 12:40 пользователь Alex Khrenov написал: > В Wed, 16 Oct 2013 23:40:41 +0300 > "George L. Yermulnik" пишет: > > > > Но стоящий до этого сервер на 8.2 и на 9.0 на более слабом железе > > > отлично справлялся... > > > > Справлялся или просто не сообщал о дропнутых коннектах? =) > > > > У меня именно справлялся на 9.1. После апгрейда до 9.2 все начало дико > тормозить, а в логах появилась эта бурда. Пришлось откатить ядро на > 9.1. Так и работает пока. Мир от 9.2, ядро 9.1. > Интересно, это только при апгрейде такое или есть случаи похожего > поведения при чистой установке 9.2? В моем случае это установка чистой 9.2
[freebsd] Re: [freebsd] Новый матюк в dmesg
16 октября 2013 г., 22:26 пользователь George L. Yermulnik написал: > Hello! > > On Wed, 16 Oct 2013 at 19:29:43 (+0300), greenh wrote: > > > Господа, подскажите плз, что это может быть за матюк: sonewconn: pcb > > 0xfe0404548690: Listen queue overflow: 151 already in queue awaiting > > acceptance > > Перенес проект с довольно большой нагрузкой на новый сервак с 9.2 и > увидел > > такое в dmesg. При этом мускул ругается на too many connectiion. > Настройки > > sysctl скопированы 1 в 1 > > Появилось в 9-ке. Я тоже удивился. Гугл из стоящего внимания выдаёт вот > это: > http://lists.freebsd.org/pipermail/freebsd-net/2013-July/036016.html > > Странно как то получается. По этим ссылкам выходит, что машинка не успевает обрабатывать входящий поток соединений? Но стоящий до этого сервер на 8.2 и на 9.0 на более слабом железе отлично справлялся...
[freebsd] Новый матюк в dmesg
Господа, подскажите плз, что это может быть за матюк: sonewconn: pcb 0xfe0404548690: Listen queue overflow: 151 already in queue awaiting acceptance Перенес проект с довольно большой нагрузкой на новый сервак с 9.2 и увидел такое в dmesg. При этом мускул ругается на too many connectiion. Настройки sysctl скопированы 1 в 1
[freebsd] ZFS и mysql
База одного из проектов выросла примерно до 40 гиг и бекапить mysqldump ом ее стало малореально. Было принято творческое решение перейти на zfs и бекапы снапшотом. После переезда на существенно более мощную машину с zfs выяснилось, что что запросы к таблицам начали выполняться примерно в 3-5 раз медленее, чем до этого. Вопрос - может ли это быть связанно с переходом на zfs, а если да - то как фиксить и куда смотреть?
Re: [freebsd] layer 7 filter
6 сентября 2013 г., 11:01 пользователь Anton Sayetsky написал: > 6 сентября 2013 г., 10:32 пользователь Eugene Grosbein > написал: > > On 06.09.2013 14:14, Anton Sayetsky wrote: > >> Но есть и недостатки. Например, скайп подглючивать будет. Собственно, > >> это ведь тоже encrypted p2p. > > > > Разве скайп всё ещё p2p? > p2p, куда ж он денется > jason@jw:~$ sockstat -46 | grep skype | wc -l > 88 > Разве нет? > и на что это должно намекать? на то что он p2p?
[freebsd] статус *tcp
Добрый день подскажите плз, что обозначает статус процесса *tcp 3652 www1 880 588M 63724K *tcp1 0:13 53.56% nginx 3664 www1 870 592M 72404K *tcp9 0:18 49.37% nginx 3647 www1 850 580M 58852K CPU14 14 0:28 42.58% nginx
[freebsd] Опять проблемы с мемкеш
Добрый день Сломал уже всю голову, куда смотреть дальше не знаю Имеется сервер, на котором настроенна связка nginx+php-fpm+memcache периодически (в последнее время с ростом трафа все чаще и чаще) memcache "залипает" и в логах пхп появляется вот такое [29-Jul-2013 12:04:59 UTC] PHP Warning: Memcache::connect() [memcache.connect]: Can't connect to localhost:11211, Operation timed out (60) in /home/client//classes/Cache.php on line 51 при этом nw10# netstat -an | grep 11211 | grep ESTA | wc -l 400 в результате пхп тормозит, очереди растут и все встает раком # uname -a FreeBSD nw10 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1: Wed Oct 24 13:44:32 MSK 2012 root@nw10:/usr/obj/usr/src/sys/GREENH amd64 # netstat -m 46570/227480/274050 mbufs in use (current/cache/total) 20366/24568/44934/862144 mbuf clusters in use (current/cache/total/max) 20366/24435 mbuf+clusters out of packet secondary zone in use (current/cache) 3080/18980/22060/128000 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 64694K/181926K/246620K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 680638 requests for I/O initiated by sendfile 0 calls to protocol drain routines
[freebsd] Re: [freebsd] Re: [freebsd] nmbclusters и автотюннинг
Я так понял, что он сам тюнится исходя из kern.ipc.maxsockets и прочая.. 19 июля 2013 г., 14:45 пользователь Sayetsky Anton написал: > releng/9.1 - неправда. По крайней мере, с дефолтными настройками. >
[freebsd] nmbclusters и автотюннинг
Дамы и господа, подскажите плз До меня дошли слухи, что nmbclusters уже нет нужды настраивать, т.к. его допилили до автотюнинга. Насколько это правда?
[freebsd] Re: [freebsd] Re: [freebsd] Залипает пхп при высокой нагрузке
Скажите плз, а у вас мемкеш и сервер приложений разнесены? и какую пхп либу вы используете? php-memcache или php-memcached? 17 июля 2013 г., 20:04 пользователь Anton Yuzhaninov написал: > On 07/17/13 20:50, greenh wrote: > >> Долгим дебагом с разработчиками выяснили, что проблема в мемкеше, который >> при >> 4-6k rps начал захлебываться. Это нормально? >> > > Нет. У нас до 90k get запросов в секунду на persistent connections > (memcached 1.4.13), на относительно старом железе (CPU Intel Xeon E5420). > > Про мемкешед могу посоветовать: > 1. объекты больше килобайта (или нескольких) сжимать (большинство > библиотек делают это прозрачно). > 2. Там где это возможно использовать getMulti вместо нескольких get > 3. постоянные подключения тоже немного помогают. > > Еще можно попробовать посмотреть через tcpdump насколько быстро идут > ответы на запросы. >
[freebsd] Re: [freebsd] Залипает пхп при высокой нагрузке
1 и 2 хватает валом. php-fpm процессов стоит лимит по 2к сейчас разгоню на 5к, но это как то перебор 16 июля 2013 г., 20:21 пользователь Anton Yuzhaninov написал: > On 07/16/13 20:52, greenh wrote: > >> Добрый день >> Наткнулся на мистику, которой не могу найти объяснений. >> Раз в день, примерно с 18 до 20 по МСК (пик нагрузки) начинается >> необъяснимый >> рост очереди к Php-fpm от nginx >> Netstat -Lan >> ... >> unix 28444/0/60096 /home/mg/run/socket.mg <http://socket.mg> >> >> ... >> --- >> cat /etc/sysctl.conf >> kern.maxfiles=94 >> kern.ipc.nmbclusters=862144 >> kern.ipc.maxsockets=804800 >> kern.ipc.somaxconn=80096 >> > > IMHO somaxconn нет смысла ставить больше 8-16 тысяч... > > Очередь растет, потому что php не делает accept. > > В первую очередь стоит посмотреть top - в каких состояниях и насколько > долго висит процесс. > > Наиболее вероятная причина - он в это время занят обработкой запроса. > Можно попробовать увеличить число процессов php-fpm, но это поможет только > если: > 1. хватает RAM > 2. CPU загружен в этот момент не полностью (% idle стабильно больше нуля) > > Если php большую часть времени ждет ответа от базы данных, то увеличение > числа процессов может немного помочь, но только если сама база не упёрлась > до конца в CPU/RAM/HDD. >
[freebsd] Re: Залипает пхп при высокой нагрузке
Отправил раньше времени, сорри php-fpm.conf [mg] listen = /home/mg/run/socket.mg listen.backlog = -1 user = mg group = mg pm = dynamic pm.max_children = 2000 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 2000 uname -a FreeBSD nw10 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1: Wed Oct 24 13:44:32 MSK 2012 root@nw10:/usr/obj/usr/src/sys/GREENH amd64 и в какой то момент сайт просто перестает отвечать ЧТо это может быть? 2013/7/16 greenh > Добрый день > Наткнулся на мистику, которой не могу найти объяснений. > Раз в день, примерно с 18 до 20 по МСК (пик нагрузки) начинается > необъяснимый рост очереди к Php-fpm от nginx > Netstat -Lan > ... > unix 28444/0/60096 /home/mg/run/socket.mg > ... > --- > cat /etc/sysctl.conf > kern.maxfiles=94 > kern.ipc.nmbclusters=862144 > kern.ipc.maxsockets=804800 > kern.ipc.somaxconn=80096 > kern.threads.max_threads_per_proc=5000 > net.inet.icmp.icmplim=1 > -- > netstat -m > 60424/668291/728715 mbufs in use (current/cache/total) > 44990/478152/523142/862144 mbuf clusters in use (current/cache/total/max) > 44990/477762 mbuf+clusters out of packet secondary zone in use > (current/cache) > 3050/9750/12800/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 117286K/1162376K/1279662K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 482511 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > >
[freebsd] Залипает пхп при высокой нагрузке
Добрый день Наткнулся на мистику, которой не могу найти объяснений. Раз в день, примерно с 18 до 20 по МСК (пик нагрузки) начинается необъяснимый рост очереди к Php-fpm от nginx Netstat -Lan ... unix 28444/0/60096 /home/mg/run/socket.mg ... --- cat /etc/sysctl.conf kern.maxfiles=94 kern.ipc.nmbclusters=862144 kern.ipc.maxsockets=804800 kern.ipc.somaxconn=80096 kern.threads.max_threads_per_proc=5000 net.inet.icmp.icmplim=1 -- netstat -m 60424/668291/728715 mbufs in use (current/cache/total) 44990/478152/523142/862144 mbuf clusters in use (current/cache/total/max) 44990/477762 mbuf+clusters out of packet secondary zone in use (current/cache) 3050/9750/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 117286K/1162376K/1279662K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 482511 requests for I/O initiated by sendfile 0 calls to protocol drain routines
[freebsd] статус unp_l
Добрый день Господа, подскажите плз, что может обозначать статус процессаunp_l или unp_1?
[freebsd] Странности с ДНС
Добрый день господа, подскажите плз, что это может быть имеется 2 сервера, с которых качается программа, и на которые раунд робингом разливается траф в ДНС записи lda 1.1.1.1 lda2.2.2.2 Сегодня ночью сдох один из серверов, и обнаружили это только утром. При этом выяснилось, что количество скачек программы за прошедший период не изменилось. Как это может быть? Может ли быть такое, что клиент получив два ИП пытается пробиться по одному, а если не получается - по другому? Я всегда считал, что после запроса в кеш должен лечь только один ИП и все...
Re: Re[2]: [freebsd] rdiff-backup
du занимает слишком много времени примерно определяю по df 1 апреля 2013 г., 9:42 пользователь Alexander написал: > Hello greenh, > > Friday, March 29, 2013, 12:53:39 PM, you wrote: > > g> гиг 500-800. взвесит напряжно > > Эм-м-м... df/du? > > g> 29 марта 2013 г., 11:52 пользователь Vasiliy P. Melnik > g> написал: > >>> 2. основной контент - мелкие картинки и торрент файлы, соответсвенно > тоже мелкий > >> > >> еще бы получить ответ на вопрос - сколько? > >> > >> я с винды бекаплю просто - запускаю free file sync (типа rsync-а), он > >> синхронизирует файлы, а потом делаю снапшот zfs. У меня обычно > >> набирается несколько мегабайт - мало в общем. Поэтому и весит вопрос - > >> насколько сильно меняются файлы за время между резервами. > -- > Best regards, > Alexandermailto:albor...@gmail.com > >
Re: [freebsd] rdiff-backup
у меня UFS и я не уверен, что удастся на ZFS переехать. хотя я почитаю 29 марта 2013 г., 11:57 пользователь Alexander Yerenkow написал: > Если изменений не так много, то вам прямая дорога к zfs send/receive. > > Вы получите возможность отправить дифф, собранный без нагрузки на CPU > средствами ФС (при настройке регулярного снепшотирования), аналогично на > приёмнике > сможете оставить возможность иметь историю изменений. > > > -- > Regards, > Alexander Yerenkow
Re: [freebsd] rdiff-backup
гиг 500-800. взвесит напряжно 29 марта 2013 г., 11:52 пользователь Vasiliy P. Melnik написал: >> 2. основной контент - мелкие картинки и торрент файлы, соответсвенно тоже >> мелкий > > еще бы получить ответ на вопрос - сколько? > > я с винды бекаплю просто - запускаю free file sync (типа rsync-а), он > синхронизирует файлы, а потом делаю снапшот zfs. У меня обычно > набирается несколько мегабайт - мало в общем. Поэтому и весит вопрос - > насколько сильно меняются файлы за время между резервами.
Re: [freebsd] rdiff-backup
Господа 1. rsync и scp не хотелось бы, т.к. по rdiff-backup можно восстановить состояние "на вчера". Т.е., грубо говоря, если не винт сдохнет, а у скрипта или программера съедет крыша и он снесет файло, то я смогу восстановить состояние. rsync мне такой возмодности не даст 2. основной контент - мелкие картинки и торрент файлы, соответсвенно тоже мелкий 29 марта 2013 г., 11:09 пользователь Volodymyr Kostyrko написал: > 28.03.2013 22:51, Кирилл Малышев пишет: >> >> 28 марта 2013 г., 13:37 пользователь Volodymyr Kostyrko >> mailto:c.kw...@gmail.com>> написал: >> >> >> 28.03.2013 13:13, greenh пишет: >> >> Доброе время суток >> Господа, подскажите плз, как правильнее поступить >> Имеется серв, на нем несколько сотен тыщ файлов >> и хочется его бекапить >> я для бекапа решил воспользоваться rdiff-backup >> но есть одна незадача >> между серверами периодически (не на долго) рвется канал, и >> innitial >> backup не проходит. после этого rdiff-backup удаляет то, что он >> уже >> сделал и начинает сначала. Можно ли как нить убедить его это не >> делать, или как то по другому выкрутится из ситуации? >> >> >> Когда у меня была та же проблема со снепшотами на зфс я первый дамп >> выкладывал по http и тянул с докачкой. >> >> -- >> Sphinx of black quartz, judge my vow. >> >> >> rsync? > > > Когда изменений в итерация метров пять а файлов в папке больше 10 rsync > проигрывает сразу по двум пунктам: > 1. Ему каждый раз нужно рассмотреть и сверить всю иерархию - это > дополнительная нехилая нагрузка на диски с обоих сторон. > 2. Если данный запуск был неудачен то в снепшотах сохраняется совсем не та > подборка файлов. Точнее только те, которые оно смогло/успело пройти. > > > -- > Sphinx of black quartz, judge my vow.
[freebsd] rdiff-backup
Доброе время суток Господа, подскажите плз, как правильнее поступить Имеется серв, на нем несколько сотен тыщ файлов и хочется его бекапить я для бекапа решил воспользоваться rdiff-backup но есть одна незадача между серверами периодически (не на долго) рвется канал, и innitial backup не проходит. после этого rdiff-backup удаляет то, что он уже сделал и начинает сначала. Можно ли как нить убедить его это не делать, или как то по другому выкрутится из ситуации?
[freebsd] Re: [freebsd] Странности в логе
>> >> bge0: watchdog timeout -- resetting > > Было такое. Добавил > > hw.bge.allow_asf="0" > > в /boot/loader.conf и ребутнул - попустило. А сетевуху при этот он реально гасит или только матерится?
[freebsd] Странности в логе
Люди добрые, подскажите, что может обозначать вот такое вот в логах Feb 13 17:59:35 kazino kernel: bge0: link state changed to UP Feb 13 19:00:41 kazino kernel: bge0: watchdog timeout -- resetting Feb 13 19:00:41 kazino kernel: bge0: link state changed to DOWN Feb 13 19:00:42 kazino kernel: bge0: link state changed to UP Feb 13 20:05:54 kazino kernel: bge0: watchdog timeout -- resetting Feb 13 20:05:54 kazino kernel: bge0: link state changed to DOWN Feb 13 20:05:56 kazino kernel: bge0: link state changed to UP Feb 13 21:07:51 kazino kernel: bge0: watchdog timeout -- resetting Feb 13 21:07:51 kazino kernel: bge0: link state changed to DOWN Feb 13 21:07:52 kazino kernel: bge0: link state changed to UP Feb 13 22:00:57 kazino kernel: bge0: watchdog timeout -- resetting Feb 13 22:00:57 kazino kernel: bge0: link state changed to DOWN Feb 13 22:00:58 kazino kernel: bge0: link state changed to UP Feb 13 22:55:19 kazino kernel: bge0: watchdog timeout -- resetting Feb 13 22:55:19 kazino kernel: bge0: link state changed to DOWN Feb 13 22:55:20 kazino kernel: bge0: link state changed to UP
[freebsd] ipsec+nat
Народ, подскажите плз Это вообще решаемо? Не получается поднять L2TP/IPSec соединение из-под ната на сервер с freebsd8.3 (mpd5+ipsec-tools+some patches). как только windows XP, windows 7, iPhone 3gs (5.1) оказываются в интернете без ната (PPPoE или GPRS) - соединение корректно устанавливается, поднимается шифрация и все работает. Проверялось из-под различных натов (FreeBSD gateway, Dlink DIR-300).
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] ÐÑÑÐ¾ÐºÐ°Ñ Ð½Ð°Ð³ÑÑзка
> Ñ Ð±ÑквалÑно на днÑÑ Ð¿Ñобовал, на 8.2 пÑавда. > Ñайлов бÑло <150k в ÑлÑÑае Ñ tmpfs, благодаÑÑ ÑомÑ, ÑÑо > оÑвлекÑÑ Ð¾Ñ Ñого workspace оно и доÑÑиÑалоÑÑ. ÐолÑÑе 3 минÑÑ ÑÑиÑало, > ÑÑо Ð´Ð¾Ñ ÐµÑа, как мне кажеÑÑÑ. пÑи ÑÑом find, наÑÑавленнÑй на ÑÐ¾Ñ Ð¶Ðµ > каÑалог, но Ñже Ñ ufs на Ñлед. денÑ, пÑимеÑно в Ñоже вÑемÑ, наÑÑиÑал > ~420к (ÑеÑÑии Ð¿Ñ Ð¿-ÑнÑе Ñипа sess_001p8n9vbqphdbjrchf0s6ngg7) > ÐÐ¾Ñ Ð¸Ð½ÑеÑеÑно, еÑÑÑ ÐºÐ°ÐºÐ¾Ð¹ ниÑÑ Ð²Ð¼ÐµÐ½ÑемÑй Ð¼ÐµÑ Ð°Ð½Ð¸Ð·Ð¼, позволÑÑÑий Ñ ÑаниÑÑ ÑеcÑии в ÑÑÑÑкÑÑÑе вида aa/bb/cc/dd/ee и ÑÑо ÑÑо за ÑалÑй вида php193y786409283262893727?
[freebsd] Re: [freebsd] Re: [freebsd] ÐÑÑÐ¾ÐºÐ°Ñ Ð½Ð°Ð³ÑÑзка
> Ð½Ñ Ñак ÑделайÑе вÑем Ñ Ð¾ÑоÑо :) ÑÐ°Ð·Ð¼ÐµÑ Ð¾Ð¿ÑеделиÑе Ñами > > tmpmfs="YES"# Set to YES to always create an mfs > /tmp, NO to never > tmpsize="128m" # Size of mfs /tmp if created > а ÑÑо бÑÐ´ÐµÑ Ð¿Ñи пеÑеполнении? и можно ли tmpmfs делаÑÑ Ð½Ðµ в /tmp?
[freebsd] Re: [freebsd] Re: [freebsd] Высокая нагрузка
10 января 2013 г., 19:34 пользователь Vasiliy P. Melnik написал: > >> > Куды бечь? (с) >> >> top -S >> http://pastebin.com/81vE6sB1 > > > > под каждого юзера апач запускаете ? или это все-таки suexec? > там php-fpm Eugene Grosbein низкий поклон - пхп гадил в /var/tmp своими кусками, и их там набралось 200к
[freebsd] Re: [freebsd] Высокая нагрузка
10 января 2013 г., 19:22 пользователь greenh написал: > 5 января 2013 г., 9:55 пользователь Eugene Grosbein > написал: >> 05.01.2013 14:50, greenh пишет: >> >>>>> 4 января 2013 г., 15:10 пользователь Eugene Grosbein >>>>> написал: >>>>>> sysctl vfs.ufs | fgrep mem >>>>> >>>>> vfs.ufs.dirhash_lowmemcount: 0 >>>>> vfs.ufs.dirhash_mem: 53137380 >>>>> vfs.ufs.dirhash_maxmem: 80646144 >>>> >>>> Это в момент высокого потребления system time и высокого LA? >>>> С одной стороны, упирания в maxmem нет, с другой - текущее потребление >>>> dirhash в более чем 50MB это очень много и подтверждает предположение >>>> о существовании каталога с огромным количеством файлов. >>>> >>>> Такие каталоги делают некоторые php-движки, накапливая в них огромное >>>> количество устаревших сессионных файлов и пытаясь удалять старые сессии >>>> не фоновым процессом, а непосредственно во время обработки юзеровского >>>> HTTP-запроса. Этот braindamage лечится только отключением такого поведения >>>> движка >>>> (чтобы он во время выполения запросов не пытался заниматься посторонними >>>> делами >>>> типа очистки сессионного каталога) плюс переключением движка на хранение >>>> сессий в структуре каталогов вместо одного плоского. A чистку старых сессий >>>> выполнять cron'ом. >>> >>> Нет, это не в момент высокой нагрузки, т.к. ситуация >>> стабилизировалась, и поймать ее пока не получается. >> >> Повторится. > > Повторилось > sysctl vfs.ufs | fgrep mem > vfs.ufs.dirhash_lowmemcount: 0 > vfs.ufs.dirhash_mem: 21596046 > vfs.ufs.dirhash_maxmem: 80646144 > > Куды бечь? (с) top -S http://pastebin.com/81vE6sB1
[freebsd] Re: [freebsd] Высокая нагрузка
5 января 2013 г., 9:55 пользователь Eugene Grosbein написал: > 05.01.2013 14:50, greenh пишет: > >>>> 4 января 2013 г., 15:10 пользователь Eugene Grosbein >>>> написал: >>>>> sysctl vfs.ufs | fgrep mem >>>> >>>> vfs.ufs.dirhash_lowmemcount: 0 >>>> vfs.ufs.dirhash_mem: 53137380 >>>> vfs.ufs.dirhash_maxmem: 80646144 >>> >>> Это в момент высокого потребления system time и высокого LA? >>> С одной стороны, упирания в maxmem нет, с другой - текущее потребление >>> dirhash в более чем 50MB это очень много и подтверждает предположение >>> о существовании каталога с огромным количеством файлов. >>> >>> Такие каталоги делают некоторые php-движки, накапливая в них огромное >>> количество устаревших сессионных файлов и пытаясь удалять старые сессии >>> не фоновым процессом, а непосредственно во время обработки юзеровского >>> HTTP-запроса. Этот braindamage лечится только отключением такого поведения >>> движка >>> (чтобы он во время выполения запросов не пытался заниматься посторонними >>> делами >>> типа очистки сессионного каталога) плюс переключением движка на хранение >>> сессий в структуре каталогов вместо одного плоского. A чистку старых сессий >>> выполнять cron'ом. >> >> Нет, это не в момент высокой нагрузки, т.к. ситуация >> стабилизировалась, и поймать ее пока не получается. > > Повторится. Повторилось sysctl vfs.ufs | fgrep mem vfs.ufs.dirhash_lowmemcount: 0 vfs.ufs.dirhash_mem: 21596046 vfs.ufs.dirhash_maxmem: 80646144 Куды бечь? (с)
[freebsd] Re: [freebsd] Высокая нагрузка
5 января 2013 г., 9:55 пользователь Eugene Grosbein написал: > 05.01.2013 14:50, greenh пишет: > >>>> 4 января 2013 г., 15:10 пользователь Eugene Grosbein >>>> написал: >>>>> sysctl vfs.ufs | fgrep mem >>>> >>>> vfs.ufs.dirhash_lowmemcount: 0 >>>> vfs.ufs.dirhash_mem: 53137380 >>>> vfs.ufs.dirhash_maxmem: 80646144 >>> >>> Это в момент высокого потребления system time и высокого LA? >>> С одной стороны, упирания в maxmem нет, с другой - текущее потребление >>> dirhash в более чем 50MB это очень много и подтверждает предположение >>> о существовании каталога с огромным количеством файлов. >>> >>> Такие каталоги делают некоторые php-движки, накапливая в них огромное >>> количество устаревших сессионных файлов и пытаясь удалять старые сессии >>> не фоновым процессом, а непосредственно во время обработки юзеровского >>> HTTP-запроса. Этот braindamage лечится только отключением такого поведения >>> движка >>> (чтобы он во время выполения запросов не пытался заниматься посторонними >>> делами >>> типа очистки сессионного каталога) плюс переключением движка на хранение >>> сессий в структуре каталогов вместо одного плоского. A чистку старых сессий >>> выполнять cron'ом. >> >> Нет, это не в момент высокой нагрузки, т.к. ситуация >> стабилизировалась, и поймать ее пока не получается. > > Повторится. > >> Проект действительно содержит огромное количество файлов картинок, >> раскиданых по папкам, и с этим, увы, ничего сделать нельзя. > > Раскиданных по папкам это хорошо. Плохо, когда на UFS в одной папке > очень много файлов, с этим нужно бороться. Либо уходить с UFS, на ZFS > например. А если во вложенных папках? Вида xx/yy/zz/qq/file_nn.jpg? > >> Сессии проекта представляли собой большую проблемы и давно вынесены в мемкеш > > Тоже вариант (c). Вместо того, чтобы нормализовать работу приложения, можно > обкладываться кешами. Структура проекта такова, что от этого уйти не удалось :(
[freebsd] Высокая нагрузка
Подскажите плз, куда смотреть Имеется сервер FreeBSD nw10 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1: Wed Oct 24 13:44:32 MSK 2012 root@nw10:/usr/obj/usr/src/sys/GREENH amd64 На него валится http трафик в среднем около 2k rps В какой то момент я стал замечать увеличение LA, в основном скакообразно до значений 100-600 при этом очень сильльно растет system top -S last pid: 35908; load averages: 105.38, 68.05, 34.35 up 0+00:14:49 15:45:12 1489 processes:97 running, 1360 sleeping, 1 waiting, 31 lock CPU: 13.9% user, 0.0% nice, 84.8% system, 1.3% interrupt, 0.0% idle Mem: 4658M Active, 3420M Inact, 2972M Wired, 612K Cache, 2079M Buf, 36G Free Swap: 4086M Total, 4086M Free
[freebsd] Re: Сервер начинает "задыхаться"
17 октября 2012 г., 15:52 пользователь greenh написал: > Подскажите плз, када смотреть > Имеется сервер, достоточно мощный (16 ядер, 24 гига) > на него валится что то 2-3k rps на http > на 80-м порту висит nginx+php-fpm > И как только я его запускаю начинаются дикие тормоза, пинг с 150мс > увеличивается до 3000-4000с > при этом судя по топу user cpu < 10% > LA <4 > свободной памяти валом > при этом ssh сессия еле шевелится, а физическая консоль летает > > vmstat -z http://pastebin.com/DfB07hgx нормальный вид
[freebsd] порты php
В связи с тем, что в порту php5 оказывается то 5.2 то 5.3, а сейчас вообще 5.4 возник вопрос - как не пересобирая весь пых доставить модуль, или обновить пхп в рамках той же ветки, при условии что у меня стоит 5.2, на 5.3 и, особенно 5.4 я перейти не могу?
[freebsd] Nat и несколько IP
Добрый день Перечитал кучу всего, но так и не понял, в какую сторону копать Имеется серв с 1 внешним интерфейсом, на котором несколько ИП На нем впн сервер, на который подключаются клиенты и через нат уходят в мир Задача: сделать так чтобы каждый раз человек получал разные ИП. При этом очень хотелось бы, что бы зайдя на сайт с одного ип, человек до переподключения оставался с него же. Т.е. пробрасывать человека через рандомный nat крайне не хочется. Да и не совсем понятно, как заставить наты на одном интерфейсе работать с разными ИП. Подскажите плз направление.
Re: [freebsd] ECMP + ipfw nat
12 декабря 2011 г. 17:50 пользователь Зеленяк Алексей написал: > On 12.12.2011 17:42, greenh wrote: > > То есть, вполне может получиться ситуация, при которой пользователь, > > зайдя на страницу с одного адреса, а перейдя по ссылке - оказаться уже > > с другого? > > > > Да. > > Боюсь что некоторым сайтам/серверам это не понравится. вконтакт точно обидится
Re: [freebsd] Ipfw & limit connections
Если не секрет, а чем цель этих действий?
12 декабря 2011 г. 12:22 пользователь Slawa Olhovchenkov
написал:
> On Mon, Dec 12, 2011 at 12:18:29PM +0200, Vladislav V. Prodan wrote:
>
> > Правильно ли я думаю, что:
> >
> > #разрешить для IP источника открывать на мой порт не более 50 соединений
> > ipfw add pass all from any to me 80 limit src-addr 50
> >
> > #разрешить для моих IP (назначения) при соединении на порт 80 открывать
> > не более 50 соединений
> > ipfw add pass all from any to me 80 limit dst-addr 50
> >
> >
> > В каком контексте применимо
> > limit { src-port | dst-port} N
> >
> > ?
>
> ipfw?
> 42?
>
> > Какими параметрами sysctl быстро гасить соединения, которые висят в
> > лимитах соединения?
> > 05200 33 25005 (116s) LIMIT tcp 79.126.107.221 1587 <-> x.x.x.x 80
>
> tcpdrop
>
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] torrent-ы порезать
22 ноября 2011 г. 10:51 пользователь Lystopad Olexandr написал: > Hello, Oleksandr V. Typlyns'kyi! > > On Tue, Nov 22, 2011 at 10:14:55AM +0200 > ast...@wangsamp.km.ua wrote about "[freebsd] Re: [freebsd] Re: [freebsd] > Re: [freebsd] Re: [freebsd] torrent-ы порезать": > > Today Nov 22, 2011 at 10:05 Sayetsky Anton wrote: > > > > > > А если урезать количество сессий этим нехорошим человекам? > > > > Возможность забить весь канал будет меньше. > > > > > > Кстати, вариант. > > > Но... > > > Сколько сессий нужно одному человеку? > > > Допустим, выяснили, что браузер открывает 16 коннектов на 1 сайт, > > > решили порезать товарищу до 100 коннектов всего. Он запускает торрент, > > > и сайты перестают открываться. А человек хочет во время закачки > > > торрентов открыть rada.gov.ua и прочесть какой-либо закон. > > > > В Shareaza, например, можно ограничивать количество сессий и полосу. > > Думаю, и в других клиентах это должно быть, а нету - поменяет. > > Поставит торренту в 50 - будут работать и сайты, и качалка. > > imho, надо резать на каждый хост фиксированную полосу и все. > Нехватает? А торрент включен?! О! > > Я поступал похоже. Статистика по трафу дискретно за 5 мин на ип. То есть у меня была инфа о том, сколько человек скачал/отдал за каждые конкретные 5 мин. И для некоторых товарищей зарезка полосы. И на момент жалобы смотрим, сколько мы качали в этот момент. Если много - человек отправляется с комментарием "отключай торренты и не мороч голову". После первой разборки с начальством и демонстрации статистики количество приходящих очень сильно уменьшилось. И, да, статистика была доступна ВСЕМ, по принципу - страна должна знать своих героев. Пару раз таким образом находили вирусы :)
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] RE: [freebsd] Re: [freebsd] Системный администратор UNIX-серверов
6 ноября 2011 г. 15:22 пользователь Alexander Yerenkow написал: > ИМХО отношения работодатель-работник это всегда конфликт интересов. Как > любой конфликт, это или решается компромиссом (если все стороны > одновременно удовлетворить нельзя), или не решается вообще (разбегаются). А > факторы есть всегда с обоих сторон, не всегда работодатель купается в > роскоши, и не всегда сотрудник полностью всё своё рабочее время посвящает > работе (есть такие, приходят попозже, на кофе-чаи уходит суммарно чуть ли > не час в день, долго обедают, часто "надо пораньше уйти" и т.п.). Если есть > причины для изменения изначальных условий - надо вести конструктивный > разговор. > К чему я это всё. Вот вы сейчас, не зная ситуации, не разбираясь в > тонкостях пытаетесь дать оценку компании которая хочет найти сотрудника. > "На том заводе всё плохо, потому что у них вон окна грязные." > Думаю здесь все взрослые люди, и сами воспримут информацию, без > теоретизированных субъективных мнений :) > Да мы не про компанию, мы про принципы взаимодействия работодатель-работник в принципе. Про компанию я лично ничего не знаю и сказать ничего не могу
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] RE: [freebsd] Re: [freebsd] Системный администратор UNIX-серверов
6 ноября 2011 г. 13:05 пользователь Алексей Бобок написал: > слишком меркантильная аудитория, Вам не кажется? > > АГа. денег хотят, еще, наверно, в отпуск захотят, премии и КЗОТ Жуть просто :) > 6 ноября 2011 г. 12:54 пользователь Michael A. Revenko > написал: > > 11/5/2011 10:25 PM, Александр Коваленко пишет: > > > > В данном случае чувак поступил с "меньшим злом" для работодателя, > варианты > > могли бы быть куда веселее, например, нашёл бы себе другую работу, > написал > > бы заявление на отпуск и потом бы еще и заявление об уходе в догонку > вот > > это было бы не красиво... без диалога и тому подобных соплей... и пусть > > работодатель экстренно ищет ему замену... и очень может быть, что замена > > будет стоить именно столько сколько попросил предыдущий чел а бизнес > > процессы уже вроде и пострадали > > > > Я прекрасно понимаю, что бывают разные ситуации... но я бы не стал клеить > > ярлыки на людей, типа он не развивается (вообще какой-то бред), значит > > подход к человеку не нашли именно Вы, не нащупали то направление в > котором > > ему будет интересно развиваться а не тратить тупо своё время. А работа в > ИТ > > свере это не самый лёгкий вариант я знаю перца который в с пятницы на > > субботу спит 17 часов чтобы отоспаться. > > > > Часто густо под ейчаровскими словами "развитие" подразумевается, что > > работнику нужно делать больше работы, а платить ему не нужно за это, > пусть > > он думает, что он развивается > > > > Я представляю в красках негодование Работодателя... > > - "вообще подумать только, кто рабам давал слово, ты посмотри на него, > > зарплату потребовал... хер ему по всей морде, да я только свисну на > фрибсд и > > тут очередь выстоиться равшанов и джумшутов и будут работать за миску > > похлёбки" > > > > А особо гнусные рабовладельцы не гнушаются и более интересными методами в > > догонку уходящему - типа да я обзвоню всех в киеве, ты хер работу > > найдёшь.. > > > > Если работодатель не может удержать сотрудника, значит и про коллектив > всё > > сказки, нет там никой атмосферы, нету системы мотивации, в данном случае > > сотрудник банально попросил денег, а не повышения (так называемого > > развития), компанейского автомобиля, обеды в сем стейк хаусе, спорт зал > или > > ещё что то из так называемых социальных пакетов, кстати там еще пишут что > > конкурентная зартплата - а может перец головой покрутил по сторонам и > понял > > что и о зарплате всё сказки тоже ... > > > > Думаю с понедльника, пост будет очень живо обсуждаться > > > > ЗЫ > > А одесситу особый респект, молодец, в разряд лимиты его не зачислят > > > > * "Vasiliy P. Melnik" [Sat, 5 Nov 2011 21:37:27 > +0300]: > > > >> > Вот если развивается и если растёт, то, по хорошему, компания сама > >> подстроится. > >> > А вот если нет и зарплата устраивает, но "хочу больше, а то уволюсь" > >> - это шантаж. > >> > >> http://ru.wikipedia.org/wiki/Шантаж > >> > >> В настоящее время слово "шантаж" нередко используется в широком смысле - > >> как > >> угроза любых негативных последствий в случае невыполнения требований. > >> Расчёт > >> шантажиста при этом заключается в том, что последствия являются для > >> шантажируемой стороны более тяжёлыми и неприемлемыми, чем выполнение его > >> требований, и что шантажируемая сторона пойдёт на их выполнение как на > >> меньшее зло. > >> > >> Одной из основных черт шантажа является завышенность требований > >> шантажиста > >> по сравнению с нормами окружающего мира. В настоящее время в некоторых > >> странах наблюдается чрезмерное употребление слова шантаж в политических > >> и > >> экономических вопросах, довольно часто не соответствующее сущности этого > >> понятия. > >> > >> > >> > >> > > > > > > > > > > -- > > Александр Коваленко. > > > > А топикстартера не видать. Что наводит на сомнительные размышления > > > > -- > > WBR, Mike > > > > -- > Think before you print. > Best regards, Alexey Bobok. >
[freebsd] Re: [freebsd] Re: [freebsd] Системный администратор UNIX-серверов
5 ноября 2011 г. 19:45 пользователь Александр Коваленко < olexandr.kovale...@rambler.ru> написал: > Странно как-то БАМ вроде уже построили и живём при капитализме и > работать вроде хочеться именно что за зарплату... > > согласен, работодатель таки должен платить конкурентноспособную зарплату, > а не вешать лапшу на уши... рассказами про коллектив. > > Хотелось бы посмотреть статистику оборота голов в той компании, а то как > то уж частенько объявления появляются, видмо сказками не все могут питаться. > Знаете, например лично я не всегда выбираю работу по принципу "максимальная ЗП". ИМХО (для меня) ЗП должна быть как то более менее адекватная, но кроме цифры еще есть множество факторов, влияющих на принятие решение. > > > * greenh [Sat, 5 Nov 2011 18:59:50 +0200]: > > > 5 ноября 2011 г. 15:45 пользователь Vladislav V. Prodan > > написал: > > > > > 05.11.2011 14:44, Алексей Бобок пишет: > > > > 5 ноября 2011 г. 14:41 пользователь Oleksandr V. Typlyns'kyi > > > > написал: > > > >> Скорее не могут шантажировать "хочу больше, а то уволюсь" > > > >> Держать шантажистов в штате стоит только до момента нахождения им > > > замены. > > > > > > > > Держать в штате людей сомнительных человеческих качеств вообще не > > стоит. > > > > > > > > > > Это каких, простите? > > > > > > Лично я шантаж не применяю, но просить добавки можно, другое дело, что > > > некоторые руководители делают замену персонала каждые два года, ибо > > так > > > проще не повышать зп или иначе стимулировать сотрудников. > > > > > > P.S. В Киев не собираюсь, аутсорс пока еще кормит [image: :)] > > > > > > > Мне всегда страннен такой подход к персоналу. Неужели подъем ЗП более > > критичен, чем слаженный, сработавшийся коллектив? > > > > > > -- > Александр Коваленко. >
Re: [freebsd] atacontrol mode ad0
> > > Коллеги, простите нуба. > > > > Проблема > > > > Если: > > atacontrol mode ad0 > > current mode = UDMA100 > > То: > > в приходящих отчетах наблюдаю > > > > +ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=4086351 > > +ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=4086383 > > +ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=4086383 > > ... > > > > Меняю > > atacontrol mode ad0 UDMA66 > > current mode = UDMA66 > > > > В отчетах - чисто. > > > > Как после перезагрузки автоматически включить atacontrol mode ad0 UDMA66? > > Прочитать man ata про настройки в /boot/loader.conf: > > hint.ata.X.devX.mode > limits initial ATA mode for specified device on specified channel. > > hint.ata.X.mode > limits initial ATA mode for every device on specified channel. > Такое поведение винта/матери не смущает? не посыпется ли оно в ближайшем будущем? Смарт что нить говорит?
[freebsd] Re: [freebsd] Системный администратор UNIX-серверов
5 ноября 2011 г. 15:45 пользователь Vladislav V. Prodan написал: > 05.11.2011 14:44, Алексей Бобок пишет: > > 5 ноября 2011 г. 14:41 пользователь Oleksandr V. Typlyns'kyi > > написал: > >> Скорее не могут шантажировать "хочу больше, а то уволюсь" > >> Держать шантажистов в штате стоит только до момента нахождения им > замены. > > > > Держать в штате людей сомнительных человеческих качеств вообще не стоит. > > > > Это каких, простите? > > Лично я шантаж не применяю, но просить добавки можно, другое дело, что > некоторые руководители делают замену персонала каждые два года, ибо так > проще не повышать зп или иначе стимулировать сотрудников. > > P.S. В Киев не собираюсь, аутсорс пока еще кормит :) > > Мне всегда страннен такой подход к персоналу. Неужели подъем ЗП более критичен, чем слаженный, сработавшийся коллектив?
Re: [freebsd] mysql backup
mount -u -o snapshot /var/snapshot/test /var или /usr/ports/sysutils/freebsd-snapshot 31 октября 2011 г. 15:54 пользователь Sergey Kobzar написал: > On 10/31/11 16:47, greenh wrote: > >> база 30 гиг >> раздел 1тб >> на разделе более ничего нет >> snapshot make /R10:backup - 2 минуты 10 секунд. это нормально? >> > > ХЗ. Чем снэпшот делаете? > > У меня на Linux (LVM): > > [02:10:01] Locking databases > [02:10:01] Taking LVM snapshot > [02:10:01] Unlocking databases > [02:10:09] Coping databases to /home/backup/mysql/mysql-0 >
Re: [freebsd] mysql backup
база 30 гиг раздел 1тб на разделе более ничего нет snapshot make /R10:backup - 2 минуты 10 секунд. это нормально? 27 октября 2011 г. 19:38 пользователь Sergey Kobzar написал: > On 10/27/11 19:05, Sergey Kobzar wrote: > >> On 10/27/11 18:36, Sayetsky Anton wrote: >> >> Как-то так. Восстанавливается полный дамп часа 3, наверное. Давно не >>> было необходимости совершать сие ): >>> >> >> В случае fs snapshot в разы меньше. У меня на базе в 250Г - 20-30 минут. >> > > Забыл добавить, время всстановления для innodb таблиц еще зависит и от > innodb_buffer_pool_size. У меня этот параметр установлен в 36G. На > серверах, где памяти поменьше, чек будет выполняться быстрее. >
[freebsd] Re: [freebsd] Re: [freebsd] mysql тормоза
селекты, инсерты.. все как обычно 28 октября 2011 г. 15:46 пользователь Алексей Бобок написал: > а что в тридах? > > 28 октября 2011 г. 15:43 пользователь greenh написал: > > Объем был такой же >> Был большой креш, переезд на несколько более слабое железо, восстановление >> из бекапа (из дампа). в общем много всего >> Что еще интересного заметил >> После перезапуска mysql сервера наинаются дикие томоза, по 1к-1,5к тредов, >> в общем жуть >> Проходит какое то время - и все в одно мгновение нормализцуется, пропадают >> очереди. все летает. >> Такое ощущение, что либо какой то кеш заполняется, либо что то еще. >> >> 28 октября 2011 г. 15:34 пользователь Sergey Kobzar < >> sergey.kob...@mail.ru> написал: >> >> On 10/28/11 15:06, greenh wrote: >>> >>>> раньше летало мгновенно :( >>>> а ща в pma даже список таблиц открыть нельзя >>>> >>>> 28 октября 2011 г. 14:55 пользователь Sergey Kobzar >>>> mailto:sergey.kob...@mail.ru>**> написал: >>>> >>>> >>>>On 10/28/11 14:43, greenh wrote: >>>> >>>>Добрый день >>>>Господа, сорри за офтоп, но больше толком спросить не где >>>>Имеется 30 гиг база >>>>Все вроде работает отлично, селекты/инсерты идут, проекты >>>>крутятся, все ок >>>>Но один запрос show table status выполняется секунд 40. >>>>Что это может быть? В логах чисто >>>> >>>>my.cnf >>>>log-bin=mysql-bin >>>>expire_logs_days=7 >>>>binlog_format=mixed >>>>innodb_buffer_pool_size = 14G >>>>max_connection = 2000 >>>>key_buffer_size = 656M >>>>max_allowed_packet = 1M >>>>table_open_cache = 256 >>>>sort_buffer_size = 2M >>>>read_buffer_size = 2M >>>>read_rnd_buffer_size = 4M >>>>myisam_sort_buffer_size = 64M >>>>thread_cache_size = 32 >>>>query_cache_size= 160M >>>>thread_concurrency = 16 >>>>low_priority_updates=1 >>>>concurrent_insert=2 >>>>innodb_log_file_size = 256M >>>>query_cache_limit = 100M >>>>table_cache = 1024 >>>>innodb_additional_mem_pool___**size = 20M >>>> >>>>innodb_log_buffer_size = 8M >>>>innodb_flush_log_at_trx_commit = 2 >>>> >>>> >>>>Ну так а чего вы хотели на 30-гигово базе? >>>>MySQL выдернуть всю эту инфу надо: >>>>http://dev.mysql.com/doc/__**refman/5.1/en/show-table-__** >>>> status.html<http://dev.mysql.com/doc/__refman/5.1/en/show-table-__status.html> >>>> >>>> <http://dev.mysql.com/doc/**refman/5.1/en/show-table-**status.html<http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html> >>>> > >>>> >>> >>> А раньше какой объем был? >>> >>> У меня на базе раз в N больше вашей SHOW TABLE STATUS отрабатывает более >>> минуты. >>> >> >> > > > -- > Think before you print. > Best regards, Alexey Bobok. >
[freebsd] Re: [freebsd] mysql тормоза
да. а как же программерам без него? pma без него не умеет 28 октября 2011 г. 15:45 пользователь Sergey Kobzar написал: > On 10/28/11 15:37, greenh wrote: > >> Объем был такой же >> Был большой креш, переезд на несколько более слабое железо, >> восстановление из бекапа (из дампа). в общем много всего >> >> 28 октября 2011 г. 15:34 пользователь Sergey Kobzar >> mailto:sergey.kob...@mail.ru>**> написал: >> >>On 10/28/11 15:06, greenh wrote: >> >>раньше летало мгновенно :( >>а ща в pma даже список таблиц открыть нельзя >> >>28 октября 2011 г. 14:55 пользователь Sergey Kobzar >>mailto:sergey.kob...@mail.ru> >><mailto:sergey.kob...@mail.ru <mailto:sergey.kob...@mail.ru>**>__> >> >>написал: >> >> >>On 10/28/11 14:43, greenh wrote: >> >>Добрый день >>Господа, сорри за офтоп, но больше толком спросить не где >>Имеется 30 гиг база >>Все вроде работает отлично, селекты/инсерты идут, проекты >>крутятся, все ок >>Но один запрос show table status выполняется секунд 40. >>Что это может быть? В логах чисто >> >>my.cnf >>log-bin=mysql-bin >>expire_logs_days=7 >>binlog_format=mixed >>innodb_buffer_pool_size = 14G >>max_connection = 2000 >>key_buffer_size = 656M >>max_allowed_packet = 1M >>table_open_cache = 256 >>sort_buffer_size = 2M >>read_buffer_size = 2M >>read_rnd_buffer_size = 4M >>myisam_sort_buffer_size = 64M >>thread_cache_size = 32 >>query_cache_size= 160M >>thread_concurrency = 16 >>low_priority_updates=1 >>concurrent_insert=2 >>innodb_log_file_size = 256M >>query_cache_limit = 100M >>table_cache = 1024 >>innodb_additional_mem_pool**_size = 20M >> >> >>innodb_log_buffer_size = 8M >>innodb_flush_log_at_trx_commit = 2 >> >> >>Ну так а чего вы хотели на 30-гигово базе? >>MySQL выдернуть всю эту инфу надо: >>http://dev.mysql.com/doc/**refman/5.1/en/show-table-** >> status.html<http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html> >><http://dev.mysql.com/doc/__**refman/5.1/en/show-table-__** >> status.html<http://dev.mysql.com/doc/__refman/5.1/en/show-table-__status.html> >> > >> >><http://dev.mysql.com/doc/__**refman/5.1/en/show-table-__** >> status.html<http://dev.mysql.com/doc/__refman/5.1/en/show-table-__status.html> >> >> <http://dev.mysql.com/doc/**refman/5.1/en/show-table-**status.html<http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html> >> >> >> >> >>А раньше какой объем был? >> >>У меня на базе раз в N больше вашей SHOW TABLE STATUS отрабатывает >>более минуты. >> > > InnoDB? > > могу предложить только поменьше использовать SHOW TABLE STATUS. >
[freebsd] Re: [freebsd] mysql тормоза
Объем был такой же Был большой креш, переезд на несколько более слабое железо, восстановление из бекапа (из дампа). в общем много всего Что еще интересного заметил После перезапуска mysql сервера наинаются дикие томоза, по 1к-1,5к тредов, в общем жуть Проходит какое то время - и все в одно мгновение нормализцуется, пропадают очереди. все летает. Такое ощущение, что либо какой то кеш заполняется, либо что то еще. 28 октября 2011 г. 15:34 пользователь Sergey Kobzar написал: > On 10/28/11 15:06, greenh wrote: > >> раньше летало мгновенно :( >> а ща в pma даже список таблиц открыть нельзя >> >> 28 октября 2011 г. 14:55 пользователь Sergey Kobzar >> mailto:sergey.kob...@mail.ru>**> написал: >> >> >>On 10/28/11 14:43, greenh wrote: >> >>Добрый день >>Господа, сорри за офтоп, но больше толком спросить не где >>Имеется 30 гиг база >>Все вроде работает отлично, селекты/инсерты идут, проекты >>крутятся, все ок >>Но один запрос show table status выполняется секунд 40. >>Что это может быть? В логах чисто >> >>my.cnf >>log-bin=mysql-bin >>expire_logs_days=7 >>binlog_format=mixed >>innodb_buffer_pool_size = 14G >>max_connection = 2000 >>key_buffer_size = 656M >>max_allowed_packet = 1M >>table_open_cache = 256 >>sort_buffer_size = 2M >>read_buffer_size = 2M >>read_rnd_buffer_size = 4M >>myisam_sort_buffer_size = 64M >>thread_cache_size = 32 >>query_cache_size= 160M >>thread_concurrency = 16 >>low_priority_updates=1 >>concurrent_insert=2 >>innodb_log_file_size = 256M >>query_cache_limit = 100M >>table_cache = 1024 >>innodb_additional_mem_pool___**size = 20M >> >>innodb_log_buffer_size = 8M >>innodb_flush_log_at_trx_commit = 2 >> >> >>Ну так а чего вы хотели на 30-гигово базе? >>MySQL выдернуть всю эту инфу надо: >> >> http://dev.mysql.com/doc/__**refman/5.1/en/show-table-__**status.html<http://dev.mysql.com/doc/__refman/5.1/en/show-table-__status.html> >> >> <http://dev.mysql.com/doc/**refman/5.1/en/show-table-**status.html<http://dev.mysql.com/doc/refman/5.1/en/show-table-status.html> >> > >> > > А раньше какой объем был? > > У меня на базе раз в N больше вашей SHOW TABLE STATUS отрабатывает более > минуты. >
[freebsd] mysql тормоза
Добрый день Господа, сорри за офтоп, но больше толком спросить не где Имеется 30 гиг база Все вроде работает отлично, селекты/инсерты идут, проекты крутятся, все ок Но один запрос show table status выполняется секунд 40. Что это может быть? В логах чисто my.cnf log-bin=mysql-bin expire_logs_days=7 binlog_format=mixed innodb_buffer_pool_size = 14G max_connection = 2000 key_buffer_size = 656M max_allowed_packet = 1M table_open_cache = 256 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 4M myisam_sort_buffer_size = 64M thread_cache_size = 32 query_cache_size= 160M thread_concurrency = 16 low_priority_updates=1 concurrent_insert=2 innodb_log_file_size = 256M query_cache_limit = 100M table_cache = 1024 innodb_additional_mem_pool_size = 20M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2
Re: [freebsd] mysql backup
А как работает backup_db.sh? и сколько времени он буде восстанавливаться? 2011/10/27 Sayetsky Anton > 27 октября 2011 г. 16:46 пользователь Anton Yuzhaninov > написал: > > On 10/27/11 17:12, Sayetsky Anton wrote: > >> > >> Да то понятно, что хоть терабайты. Время создания архива как бы не > >> больше времени дампа было... > > > > Будет меньше, причем значительно. > > > > Потому что с диска данные будут читаться не мелкими блоками с куче > seek-ов, > > а большими, почти линейно. Да и процессор при этом будет нагружаться > > значительно меньше чем при mysqldump > > # du -hs /var/db/mysql/ > 97G/var/db/mysql/ > # time backup_db.sh &> /dev/null > > real30m10.330s > user28m48.314s > sys 0m23.827s > > Через tar проверить нет возможности... >
Re: [freebsd] mysql backup
а где еще? 27 октября 2011 г. 11:51 пользователь Sergey V. Dyatko < sergey.dya...@gmail.com> написал: > On Thu, 27 Oct 2011 11:41:34 +0300 > greenh wrote: > > > Понял, спасибо, буду смотреть в сторону zfs > > > > снепшоты есть не только в zfs;-) > > > 27 октября 2011 г. 11:26 пользователь Sergey Kobzar > > написал: > > > > > On 10/27/11 11:22, greenh wrote: > > > > > >> что не менее важно - mysqldump восстанавливается почти сутки > > >> > > >> 27 октября 2011 г. 11:20 пользователь Eugene Grosbein > > >> mailto:eu...@grosbein.net>> написал: > > >> > > >> > > >>27.10.2011 15:16, greenh пишет: > > >> > Добрый день. > > >> > Господа, подскажите плз, какие есть способы бекапа mysql > > >> > баз, при > > >>условии что есть и myisam и innodb? > > >> > > > >> > > >>mysqldump разве не справляется? > > >> > > > > > > fs snapshot. у меня работает на БД >250G. > > > > > > http://www.** > mysqlperformanceblog.com/2006/**08/21/using-lvm-for-mysql-** > > > backup-and-replication-setup/< > http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/ > > > > > > > > http://forge.mysql.com/w/**images/c/c1/MySQL_Backups_** > > > using_File_System_Snapshots-**2009-02-26.pdf< > http://forge.mysql.com/w/images/c/c1/MySQL_Backups_using_File_System_Snapshots-2009-02-26.pdf > > > > > > > > > -- > wbr, tiger >
Re: [freebsd] mysql backup
Понял, спасибо, буду смотреть в сторону zfs 27 октября 2011 г. 11:26 пользователь Sergey Kobzar написал: > On 10/27/11 11:22, greenh wrote: > >> что не менее важно - mysqldump восстанавливается почти сутки >> >> 27 октября 2011 г. 11:20 пользователь Eugene Grosbein >> mailto:eu...@grosbein.net>> написал: >> >> >>27.10.2011 15:16, greenh пишет: >> > Добрый день. >> > Господа, подскажите плз, какие есть способы бекапа mysql баз, при >>условии что есть и myisam и innodb? >> > >> >>mysqldump разве не справляется? >> > > fs snapshot. у меня работает на БД >250G. > > http://www.**mysqlperformanceblog.com/2006/**08/21/using-lvm-for-mysql-** > backup-and-replication-setup/<http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/> > > http://forge.mysql.com/w/**images/c/c1/MySQL_Backups_** > using_File_System_Snapshots-**2009-02-26.pdf<http://forge.mysql.com/w/images/c/c1/MySQL_Backups_using_File_System_Snapshots-2009-02-26.pdf> >
Re: [freebsd] mysql backup
что не менее важно - mysqldump восстанавливается почти сутки 27 октября 2011 г. 11:20 пользователь Eugene Grosbein написал: > 27.10.2011 15:16, greenh пишет: > > Добрый день. > > Господа, подскажите плз, какие есть способы бекапа mysql баз, при условии > что есть и myisam и innodb? > > > > mysqldump разве не справляется? >
Re: [freebsd] mysql backup
общий объем баз что то около 40 гиг. mysqldump будет делаться ОЧЕНЬ долго. и, я точно не помню, вроде как лочит базы xtrabackup позволяет копировать все и быстро, но под bsd есть только версия 1.4, которая с myisam еще не работает 2011/10/27 Sayetsky Anton > 27 октября 2011 г. 11:16 пользователь greenh написал: > > Добрый день. > > Господа, подскажите плз, какие есть способы бекапа mysql баз, при условии > > что есть и myisam и innodb? > > MySQL не имеет средств бэкапа. Но можете делать дамп БД через mysqldump. >
