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 крутится :-)
ext3/xfs. Reiser забыть, как страшный сон - с посадкой Ханса у этой fs будущее закончилось.
Но самый правильный вариант - переписать движки. Идея обходить при каждом дерганье скрипта стопицот каталогов - порочна, и никакое кэширование не спасет.
То, что делает Zabbix или Munin искаропки - в Кактус надо запихивать через snmp
Да ну? :-)
ps/2: snmp идеологически более верно, чем локальные скрипты.
Установлена система мониторинга Cacti Version 0.8.7e
плагины установлены.
Это вы красивые картинки имеете ввиду?
Если у вас на всю систему льется несколько миллионов показов в сутки, и до сих пор не прикручены акселераторы к пхп - это повод задуматься.
Вещь более чем стандартная.
А что с делать с картинками, например в директории их 100к, имеет смыл их рассовывать по разным директориям или в современных ОС уже пофиг.
Раскидывать в обязательном порядке.
Дело не в дряхлости/современности ОС. Дело в том, что кэш имен файлов - он работает per-directory. И это просто обычная табличная структура.
По которой, конечно, выполняется поиск - ну а чем больше записей в таблице, тем медленнее работает открытие файла.
fopen() в каталоге с 10к файлов будет работать, условно, на 50-100 мкс быстрее, чем в каталоге с 100к файлов. На 1к rps это даст уже потери в порядка 0.5 сек.
Цифры очень условные, зависят, понятное дело, от fs, от нагрузки дисковой подсистемы, итп. В реальности, кстати, могут быть еще больше.
Да, хочу заметить - это все без учета именно _поиска_ файла, то бишь дерганья всяческих readdir(). Если в коде есть обход всего дерева каталогов - то в среднем на 50-60 тыс. файлов уже наступает коллапс.
Outsourcenow добавил 01.10.2009 в 17:19
Эмм.... И как оно тогда проработало _больше_ месяца ("периодичность")? Вся база 8Tb - какой-то кеш что-ли, т.е. на данные, в общем, пофиг?
А так и работало - раз в месяц руками переключалось на следующий слейв, а умерший переливался заново.
Расскажите, поделитесь опытом. Сейчас баз такого объема у нас нет, но интересно знать какие подводные камни бывают
Подводный камень ровно один - райзер с периодичностью раз в месяц разносит в кашу. То есть совсем - похоже, рассыпаются цепочки инодов, и раздел можно переформатировать :-)
На личном опыте столкнулись с тем, что раздел на ReiserFS начинает глючить через некоторое время работы. Пришлось отключать, переносить /tmp в корень, только после этого проблемы ушли.
ReiserFS использовался для работы с /tmp
Видели б вы, что происходит с райзером на 6-8 Тб, где mysql крутится :-)
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 - косяк.
Телепатия?
Она самая.
raiserfs - в ядре, т.е. ее сопровождают. Последний коммит не более недели назад. Что не так?
Это мертвая система.
ext3/xfs. Reiser забыть, как страшный сон - с посадкой Ханса у этой fs будущее закончилось.
Но самый правильный вариант - переписать движки. Идея обходить при каждом дерганье скрипта стопицот каталогов - порочна, и никакое кэширование не спасет.