sysctl

Рейтинг
91
Регистрация
01.04.2008
Должность
BDSM ;)
Интересы
unix like
.!. O_O .!.

Миллион файлов ты и за 3 часа не успеешь удалить. Можно запустить такое удаление:

find /tmp/ -type f -exec rm -f {} \;

будет долго конечно, но оперативку не должно забивать. Да и лучше папку переименовать в какой-нибудь /tmp2/ и спокойно удалять, хоть с пониженным приоритетом, а для работы тут же создать чистую /tmp

Спасибо за разъяснения :)

OpenVZ на SATA дисках:


dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 13.585 seconds, 79.0 MB/s

OpenVZ на SAS дисках:


dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 8.55192 s, 126 MB/s

работает реально быстрее, долго напрягал интерфейс пока не вырубил галочку "вкладки сверху" :)

The WishMaster:
Чушь собачья. 95% хостингов корректно работают с сапой.

Чушь собачья ваши 95% взятые с потолка. В реальности среднестатистический хостинг конечно выдерживает сапу, но далеко не всегда, а если происходит событие типа того что я описывал ранее - лежит наглухо.

The WishMaster:

А пинг с сегодняшнего дня стал определять скорость хостинга? Ну прааастите... не знал :D :D :D

Сарказм не уместен, понятие "скорость хостинга" слишком расплывчато и зависит от множества факторов, а ping один из показателей.

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

abazaba:

Поэтому причина все же или в глюке мастерхоста (у них между прочим бывает "вдруг" и почему-то сразу предлагают вдс) или в том что мастерхост слишком быстрый (тогда это можно решить искуственными задержками).

Был у меня подобный случай искусственного занижения производительности - у клиента наглухо висела VPS, после разбора полетов оказались тяжеленные скрипты с большим i/o и кучей запросов к БД, собственно скорость открытия была не критична, а вот стабильность в приоритете, после того как nginx был заменен на apache все стало нормально работать, конечно медленно, но система не помирала успевая обрабатывать меньшее количество запросов.

The WishMaster:
Если один говнохостинг из пятидесяти не может обработать обращения к сапе - то проблемы этого говнохостера (ну, и его недоклиентов), а не сапы.

Иногда лучше жевать... Совершенно не разбираетесь в теме, это было у многих клиентов на различных шаредах и VPS'ах у различных хостеров, от наших до забугорных.

The WishMaster:
abazaba, а причем тут вообще пинг? Показатель примерно такой же значимый, как цвет сервера или имя админа.

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

юни:
Хорошо бы саповцам внедрить директиву, навроде craw delay, как раз для таких случаев.

+1 ППКС

The WishMaster:
Какие темные люди... ужас :D

Ужас - это оффтопить защищая криворуких дятлов именуемых себя разработчиками, впрочем все что я о них думаю я уже высказывал ранее

совершенно не удивительно, сошлись два фактора:

2.5% это реально очень мало для PHP

+

Сапа - зло, прилично грузящее

=

перегруз

seocore:
скорее всего скоро там будет не единица, раз LA уже начал себя так вести, вообще даже при Reallocate'ах желательно менять диск, и не надо верить в сказки, про то, что Reallocate'ы или Current_Pending_Sector в малых значениях не несут никакой опасности :)

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

Важно не количество, а динамика прироста.

Всего: 363