Outsourcenow

Рейтинг
26
Регистрация
13.08.2008
Интересы
Unix, web, highload.
Andreyka:
То, что делает Zabbix или Munin искаропки - в Кактус надо запихивать через snmp

Да ну? :-)

ps/2: snmp идеологически более верно, чем локальные скрипты.

ssoll:
Установлена система мониторинга Cacti Version 0.8.7e
плагины установлены.

Это вы красивые картинки имеете ввиду?

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

Вещь более чем стандартная.

Drow:
А что с делать с картинками, например в директории их 100к, имеет смыл их рассовывать по разным директориям или в современных ОС уже пофиг.

Раскидывать в обязательном порядке.

Дело не в дряхлости/современности ОС. Дело в том, что кэш имен файлов - он работает per-directory. И это просто обычная табличная структура.

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

fopen() в каталоге с 10к файлов будет работать, условно, на 50-100 мкс быстрее, чем в каталоге с 100к файлов. На 1к rps это даст уже потери в порядка 0.5 сек.

Цифры очень условные, зависят, понятное дело, от fs, от нагрузки дисковой подсистемы, итп. В реальности, кстати, могут быть еще больше.

Да, хочу заметить - это все без учета именно _поиска_ файла, то бишь дерганья всяческих readdir(). Если в коде есть обход всего дерева каталогов - то в среднем на 50-60 тыс. файлов уже наступает коллапс.

Outsourcenow добавил 01.10.2009 в 17:19

myhand:
Эмм.... И как оно тогда проработало _больше_ месяца ("периодичность")? Вся база 8Tb - какой-то кеш что-ли, т.е. на данные, в общем, пофиг?

А так и работало - раз в месяц руками переключалось на следующий слейв, а умерший переливался заново.

adm.unix:
Расскажите, поделитесь опытом. Сейчас баз такого объема у нас нет, но интересно знать какие подводные камни бывают

Подводный камень ровно один - райзер с периодичностью раз в месяц разносит в кашу. То есть совсем - похоже, рассыпаются цепочки инодов, и раздел можно переформатировать :-)

adm.unix:
На личном опыте столкнулись с тем, что раздел на ReiserFS начинает глючить через некоторое время работы. Пришлось отключать, переносить /tmp в корень, только после этого проблемы ушли.
ReiserFS использовался для работы с /tmp

Видели б вы, что происходит с райзером на 6-8 Тб, где mysql крутится :-)

netwind:
Outsourcenow, cпециально для тех кто не ходит по ссылкам http://forum.ispsystem.com/ru/showthread.php?t=6419

Мои соболезнования :-)

5 минут назад налитый vps из дефолтного дистрибутива:

# cat /etc/issue

CentOS release 5.2 (Final)

Kernel \r on an \m

# uname -r

2.6.18-92.1.18.el5

# locate limit.so | grep iptable

/lib64/iptables/libipt_connlimit.so

/lib64/iptables/libipt_hashlimit.so

/lib64/iptables/libipt_limit.so

#

А хотя да, там же iplimit - косяк.

myhand:
Телепатия?

Она самая.

myhand:
raiserfs - в ядре, т.е. ее сопровождают. Последний коммит не более недели назад. Что не так?

Это мертвая система.

ext3/xfs. Reiser забыть, как страшный сон - с посадкой Ханса у этой fs будущее закончилось.

Но самый правильный вариант - переписать движки. Идея обходить при каждом дерганье скрипта стопицот каталогов - порочна, и никакое кэширование не спасет.

Всего: 331