myhand

Рейтинг
278
Регистрация
16.09.2009
Himiko:
Могу сказать, что проблема именно в Debian. ISP никогда ни на какой ОС не удаляла сессии, сессии удаляются автоматически. В Debian с этим как раз проблемы, которые к панели отношения не имеют.

Еще раз. ISP полагается, что в системе включена определенная

PHP-опция. В Debian (+Ubuntu, может еще где) - session.gc_probability=0.

Почему так - написано в комментариях php.ini. Просто выбран другой механизм

очистки старых сессий.

Если уж панелька переопределяет путь сохранения для сессий и декларирует

поддержку Debian - логично ожидать, что шаги для необходимых изменений

умолчаний в php.ini она предпримет (ну, блин, выставить session.gc_probability=1

в каждом виртуалхосте).

Himiko:
P.S.: Если нужен скрипт для удаления сессий, то можно не "извращяться" и использовать что-то типа этого:
find /var/www/user/data/tmp/ -type f -mmin +60 -delete

Удалит сессии, которые старше 60 минут.

Именно это и делает _штатный_ кронтаб в дебиане. Только с привязкой

в выставленному в PHP session.gc_maxlifetime.

Proxoma:
дурацкий вопрос: как собрать статистику записи на жд каждым конкретным процессом?

На предмет _сравнить_ - можно посмотреть в сторону iotop.

Система самосборная? Какой дистрибутив?

Offtopic.

Support Megapays, да - ubunty на debian основана, а там с lenny включается

поддержка PAE

PS:http://ubuntuforums.org/showthread.php?t=855511

zexis:
Мне ведется очень эффективной идея, что бы софтовая антиттдос защита на сервере клиента автоматически отправляла бы списки обнаруженных IP адресов ботов магистральному провайдеру или в датацентр, что бы он их блокировал на входе в сам дата-центр.

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

Интересно, как бы выглядела такая блокировка для клиентов. Бот - это просто

компьютер какого-то честного Васи, который вполне может быть пользователем

одного из сайтов в ДЦ. Да еще и с динамическим IP.

Защита ведь, кроме прочего, еще и привязана к серверу. Каждый в ДЦ

аннонсирует _свой_ "плохой тырнет".

Raistlin:
А два - снапшоты я попросту никогда не делал. Нет, вру, делал один раз. 20-гигабайтный раздел снапшотился минут 10... Потому как диск активно использовался. И еще...

Скорее всего, таки не врете. Т.к. время на создание

снапшота ~= 0, там же COW используется. Работа LV, которого

снапшот делается - тормозится в дальнейшем, конечно. Но

ведь это уже другое дело.

Andreyka:
Про теневое копирование от R1Soft почему все молчат?

Никому, видимо, не интересно заниматься бесплатной рекламой закрытого

коммерческого продукта.

Raistlin:
Во-первых, снапшоты делаются не мгновенно. Для этого необходимо выделить отдельный раздел в LVM... Собственно столько он будет делаться, сколько винт будет копировать том.

Что? Т.е. просто не использовали LVM. Так и запишем, нечего стесняться.

Покуда есть место (порядка размера изменений на $LV, покуда снапшот нужен) на

группе томов ($VG) - делаем снапшот любого тома подходящего размера ($LV) - мгновенно:

lvcreate -L XXXG -s -n ${LV}_backup /dev/${VG}/${LV}

Raistlin:

P.P.S. Когда на хардах общий объем 320 гигабайт (два штуки в рейд1), и под ЛВМ отдано почти 200 гигабайт. Под один том... Куда, млин, вы снапшот делать будете? Мне отдельный диск заказывать при бекапах размером в 3 Гб?

LVM неудачно организован, скорее всего, если вся группа томов занята

одним логическим томом. У Вас 3Gb данные mysql (каталог) всего (или к чему последнее предложение)? Так вынести каталог данных mysql на отдельный

логический том, делать его снапшот.

mnn:
"Обычные" SATA должны без проблем туда встать.

Равно как и SAS. Что надо было ТС - по прежнему непонятно.

Если 50Tb+ и просмотр медиа-контента (а эт. где-нить те самые 128kbit/s по-минимому

на клиента - не шутка... То разместить все это в нормальном ДЦ - самый разумный вариант.

Всего: 4890