Vin_cent

Vin_cent
Рейтинг
171
Регистрация
22.01.2010
Pilat:
Вам надо обратиться к администратору. Судя по Вашим ответам, Вы сможете только случайно найти причину проблемы. Каждый Ваш ответ вызывает ещё больше вопросов чем было :) - например что это за виртуалка с 16Г памяти, в которой свободно 13? Виртуальной памяти 15 гигабайт, наверно?

У меня выделенный сервер (dedicated server) с 16 GB DDR3 (15.70 GB total, 2.73 GB used, на данный момент). Вроде всё обычно и понятно :)

По-поводу KVM наверное я не правильно понял-перевел эту строчку о фиче: "Rescue and Hardware Monitoring KVM layer"

admak:
может и не в тему, но можно попробовать изменить метод сжатия архива с bzip2 на gzip
архив будет немного больше размером, но возможно проц будет меньше нагружен.

в командах запаковки/распаковки замените буковку 'j' на 'z', т.е. пакуем

tar cfz archive.tgz my_directory


распаковываем
tar xzf archive.tgz


если ваши данные бинарные и плохо сжимаются, то можно вообще отказаться от компресии. тогда процу практически ничего не нужно делать

tar cf archive.tar my_directory
и
tar xf archive.tar

К сожалению, на метод сжатия архива повлиять не могу. Данные там текстовые, не бинарные.

Pilat:
138 мегабайт архив - это мелочь, при нормальной работе системы заметной нагрузки от распаковки быть не должно. Может быть, в самом архиве есть специфика - например миллион файлов? Скорее всего с памятью какие-то чудеса. Посмотрите вывод top во время распаковки. tmpfs использовать сомнительная идея, согласен с netwind. В общем данных мало - и сколько памяти у Вас, и какая виртуализация или физический сервер, и что такое в реальности /tmp ...может у Вас вообще битый рейд. В общем, надо тщательнЕе исследовать.

Согласен, архив мелкий. Там всего в нём три файла в одной папке. top показывал нагрузку %us и %sy.

Памяти 16Gb, свободно обычно около 13Gb. Виртуализация KVM. /tmp вроде обычная папка на диске. А как проверить, битый ли рейд?

В Google Webmaster сайт добавь, и узнаешь.

netwind:
Vin_cent, нет, не прикол. У всякого "серьезного бизнеса" есть условия, с которыми он вполне может смириться.
Вам же ionice не помог. Дальше-то что?

Что дальше я ещё пока не знаю. Жду знающих людей.

---------- Добавлено 15.08.2013 в 14:21 ----------

poiuty:
http://linux.die.net/man/1/ionice

Надо юзать не ionice -c 2 -n 7, а ionice -c3

Спасибо, прям сейчас и проверю.

Проверил. Стало намного лучше. Архив распаковался меньше чем за 30сек. Нагрузки небыло. НО, как только он закончил своё дело, mysql сразу же нагрузился на 800% и спустя 10-20сек, его отпустило и нагрузка исчезла.

С чем это может быть связано? Может как-то мешать то, что в качестве

tmpdir в mysql у меня /mnt/ramdisk (tmpfs /mnt/ramdisk tmpfs rw,mode=1777,size=512M 0 0) ?

Такое ощущение, что этот tar и mysql что-то поделить не могут

netwind:
Две минуты зависания потерпеть не можете ? Перенесите задачу на другое время.
Есть методы, когда ionice не справляется, но на их описание придется потратить больше двух минут.

Прикол? Я бы вас уволил за 2 минуты ежедневного простоя.

---------- Добавлено 15.08.2013 в 14:16 ----------

poiuty:
nice -n 19 ionice -c3
так попробуйте
и fs в relatime

еще можно сделать tmpfs и распаковывать в оперативку, если данные не так важны.

Подскажите, пожалуйста, как через tmpfs сделать. (сам я не администратор, не всё понимаю к сожалению)

Я успешно использую свой вариант:

############

#.htaccess

############

RewriteRule ^phpMyAdmin /cgi-bin/blockip.cgi [NC,L]

RewriteRule ^.*wwwroot\.rar$ /cgi-bin/blockip.cgi [NC,L]

RewriteRule ^.*db\.rar$ /cgi-bin/blockip.cgi [NC,L]

RewriteRule ^.*www\.zip$ /cgi-bin/blockip.cgi [NC,L]

RewriteRule ^.*admin\.php$ /cgi-bin/blockip.cgi [NC,L]

RewriteRule ^administrator$ /cgi-bin/blockip.cgi [NC,L]

############

#blockip.cgi

############

#!/usr/bin/perl

my $ip = $ENV{'REMOTE_ADDR'};

system("sudo /sbin/ip route add blackhole $ip") if $ip;

1;

######################

Очищать по крону (sudo /sbin/ip route del) раз в сутки. Этого достаточно.

Можно так проверять (больше полезной информации): http://www.tcpiputils.com/browse/ip-address/213.174.145.113

Уйдёт в минус по этому запросу в гугле. Деньги на ветер.

Повторю: google не будет накладывать пенальти, из-за 6 часов простоя

Всего: 809