vapetrov

Рейтинг
128
Регистрация
25.07.2006
alw:
А я сейчас на одном проекте уперся как раз в диски. Nginx раздает много больших файлов. Гигабитный канал занят на 50-60%, порядка 1000 коннектов, два винта в зеркале забиты в полку, в пике la доростает до неприличных значений.

Система обычно достаточно разумно кеширует файлы. Была бы память... ;)

Лично у меня обычных сата-винтов хватает чтобы отдавать практически полный гигабитный канал в 1-2 тысячи коннектов.

Вы винты смотировали с noatime, nodiratime?

А varnish совсем для другого предназначен - он кеширует страницы, на генерацию которых сервер тратит слишком много процессорного времени.

Очевидное, что приходит в голову - это сделать внутренний рерайт на специальную localtion с прописанным limit_conn.

Впрочем, лучше таки оптимизировать сайт, чтобы боты его не валили... Ведь в этом проблема?

memory_limit можно задавать в самом скрипте через ini_set();

поищите в тексте скрипта, наверняка там где-то оно задано.

Как вариант сделать на компе

SELECT ... INTO OUTFILE

а затем на сервере

LOAD DATA INFILE

подробнее в документации http://dev.mysql.com/doc/refman/5.0/en/load-data.html

8 Гиг вполне достаточно. Включайте dir_index не раздумывая.

Большой интервал записи на диск, во-первых, чреват потерей данных при внезапном ребуте.

Dimanych:
Нужно ли увеличивать commit > 5 sec для kjournald? (интервал скидывания буфера kjournald на диск)
....
Боюсь что в большинстве случаев основными тормазами жёсткого диска является как раз чтение директорий в которых большое кол-во файлов.

Вы сами на свой вопрос отвечаете ;)

Если затык в чтении, то зачем чересчур издеваться над записью? Эффекта это не даст.

Dimanych:

А также желательно ли включать dir_index? (преиндексацию директорий)?
...
размещать более 10тыс файлов в одной папке не очень хорошо

Снова ответ на свой вопрос ;)

ОЗУ сейчас недорогое, так что не жалейте денег на него - воткните побольше. Чтобы хватило и на кеш директорий и, конечно, на кеширование файлов.

Если не хватает производительности - кладите базу на отдельный винт.

Если производительности хватает, то разумнее задействовать второй винт под бакап.

Бакап можно архивировать, тогда база займет значительно меньше места.

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

Про не-sata диски я не говорил. Наоборот, требования к диску минимальные - хватит нескольких ГБ.

Svig:
еще интересует в каких версиях phpmyadmin есть уязвимости, и в какой версии нету? чтоб если что установить нормальную.

Если что-то устанавливаете из исходников - берите последнюю версию с сайта разработчиков. В дальнейшим следите за выходом новых версий и своевременно обновляйте установленное ПО.

Если же устанавливаете ПО из дистрибутива при помощи какого-то пакетного менеджера - то просто своевременно обновляйте систему, например, соответствующей утилитой (yum, aptitude и т.п.).

Разработчики дистрибутивов следят за найденными уязвимостями в ПО и (по мере сил) оперативно выпускают обновления ВСЕМ программам дистрибутива. При этом версия программы может оставаться более ранняя, чем доступна на сайте разработчика ПО, но уязвимостей в ней не будет.

Всего: 302