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 вроде обычная папка на диске. А как проверить, битый ли рейд?
netwind: Vin_cent, нет, не прикол. У всякого "серьезного бизнеса" есть условия, с которыми он вполне может смириться. Вам же ionice не помог. Дальше-то что?
Что дальше я ещё пока не знаю. Жду знающих людей.
---------- Добавлено 15.08.2013 в 14:21 ----------
Проверил. Стало намного лучше. Архив распаковался меньше чем за 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 сделать. (сам я не администратор, не всё понимаю к сожалению)
Вам надо обратиться к администратору. Судя по Вашим ответам, Вы сможете только случайно найти причину проблемы. Каждый Ваш ответ вызывает ещё больше вопросов чем было :) - например что это за виртуалка с 16Г памяти, в которой свободно 13? Виртуальной памяти 15 гигабайт, наверно?
У меня выделенный сервер (dedicated server) с 16 GB DDR3 (15.70 GB total, 2.73 GB used, на данный момент). Вроде всё обычно и понятно :)
По-поводу KVM наверное я не правильно понял-перевел эту строчку о фиче: "Rescue and Hardware Monitoring KVM layer"
может и не в тему, но можно попробовать изменить метод сжатия архива с bzip2 на gzip
архив будет немного больше размером, но возможно проц будет меньше нагружен.
в командах запаковки/распаковки замените буковку 'j' на 'z', т.е. пакуем
распаковываем
если ваши данные бинарные и плохо сжимаются, то можно вообще отказаться от компресии. тогда процу практически ничего не нужно делать
К сожалению, на метод сжатия архива повлиять не могу. Данные там текстовые, не бинарные.
138 мегабайт архив - это мелочь, при нормальной работе системы заметной нагрузки от распаковки быть не должно. Может быть, в самом архиве есть специфика - например миллион файлов? Скорее всего с памятью какие-то чудеса. Посмотрите вывод top во время распаковки. tmpfs использовать сомнительная идея, согласен с netwind. В общем данных мало - и сколько памяти у Вас, и какая виртуализация или физический сервер, и что такое в реальности /tmp ...может у Вас вообще битый рейд. В общем, надо тщательнЕе исследовать.
Согласен, архив мелкий. Там всего в нём три файла в одной папке. top показывал нагрузку %us и %sy.
Памяти 16Gb, свободно обычно около 13Gb. Виртуализация KVM. /tmp вроде обычная папка на диске. А как проверить, битый ли рейд?
В Google Webmaster сайт добавь, и узнаешь.
Vin_cent, нет, не прикол. У всякого "серьезного бизнеса" есть условия, с которыми он вполне может смириться.
Вам же ionice не помог. Дальше-то что?
Что дальше я ещё пока не знаю. Жду знающих людей.
---------- Добавлено 15.08.2013 в 14:21 ----------
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 что-то поделить не могут
Две минуты зависания потерпеть не можете ? Перенесите задачу на другое время.
Есть методы, когда ionice не справляется, но на их описание придется потратить больше двух минут.
Прикол? Я бы вас уволил за 2 минуты ежедневного простоя.
---------- Добавлено 15.08.2013 в 14:16 ----------
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 часов простоя