ZFS использование кеша (arc)

А винт точно без бедов?

Mage1, Вы хотите решить проблему, что Вы предлагаете? я думаю, что нужно попробовать несколько вариантов - чтобы решить вопрос, какие варианты Вы УЖЕ пробовали??

например:

• на php попробовать использовать fopen, fread, fseek, может, что-то другое...
• попробовать на perl, Си, etc (уже было про AIO)
• я не понимаю, почему нельзя использовать nginx для отдачи этих файлов как статику?? а может быть динамику на страницу подгружать с помощью SSI(не путать с SSL) или на Javascript.
• RDBMS/etc
• etc

помогите выкопать картошку11

Итак, обновление FreeBSD до 8.2 помогло (как раз вышел релиз). Версия ZFS 15 и все 6Гб оперативки, выделенные для кеша ZFS используются ею по назначению. Время генерации страниц сократилось со 120 до 30 миллисекунд. Но это с выключенной функцией поиска. На неё ресурсов, похоже, не хватает в принципе.

файлы о которых я писал читаются целиком, не думаю, что fopen, fread, fclose будет быстрее чем file_get_contents...

perl вместо php? :) шило на мыло? на си можно переписать, но ускорит ли это операции с диском? я думаю, нет.

заодно обновил nginx и включил AIO, разницу трудно обнаружить, но надеюсь, что это внесло какую-то лепту.

то, о чем я писал это чтение 20-ти файлов для последующей обработки, а не просто отдача пользователю. nginx-у же есть работа - картинки и файлы для скачивания. Да, за время пути собачка подросла, теперь текстовых файлов около 190 тыс. объемом 10 Гб, они содержат 1,5 млн. картинок, также имеется множество тысяч файлов для скачивания и некоторые функции также кешируются в файлы на диске. Общий объем этого хлама более 50 Гб.

вся страница сплошной динамический элемент

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

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

file_get_contents() - если по байтово считывать (буферизировать), то да... а если полностью, то нет (полностью весь файл в оперативку загонит)

http://www.google.com.ua/search?hl=ru&safe=off&q=file_get_contents+vs+fread&aq=3&aqi=g5&aql=&oq=file_get_contents+vs+

я предложил в качестве варианта :)

...напите на php открытие файлов на epool и на kqueue )))

надо было это сразу сделать...

блин, посмотрел SMART и прозрел :) Все три диска с кучей параметров в pre-fail (Reallocated_Sector_Ct, Seek_Error_Rate, Raw_Read_Error_Rate), то-то я думаю, сервер не тот, что был раньше :) Сыпятся SATA-шные винты, что, правда, и не удивительно, под такой нагрузкой да 24/7 почти год продержались...переезжаем на SAS :)

pre-fail - это тип параметра, а не классификация текущего значения параметра. они изначально pre-fail.

лучше значения покажи

истинно так, значения следующие

диск 1

диск 2

диск 3

собственно у всех имеются Reallocated_Sector_Ct, а количество Seek_Error_Rate и Raw_Read_Error_Rate астрономическое

Я подозреваю, что у вас Сигейты, от 1ТБ и выше.

Для них важно только количество Reallocated_Sector_Ct, у вас терпимо.

vlad11 добавил 25.04.2011 в 01:18

Может, вернете текст в базу и подключите Сфинкс для поиска в ней?

Если 6ГБ памяти маловато, можно немного подрезать выделение её под ZFS.

да, Seagate ST31500341AS, но всё же смущают большие количества Raw_Read_Error_Rate и Seek_Error_Rate

можно было бы попробовать, объем оперативки сопоставим с объемом текстовиков, но уже переехал на другой сервер, 24 Гб оперативки и 4х300 Гб SAS диски в RAID 10, файловая система UFS2, всё работает быстро и 15 Гб оперативки простаивает (4 Гб базе данных, 5 Гб сожрали остальные процессы). Думаю вот куда лишнюю оперативу использовать :) Думается при росте нагрузки или объемов данных закешировать в ней что-то, или перенести индекс (6Гб) поисковой системы на виртуальный диск в оперативке. Не подскажете, есть ли средства, позволяющие это сделать красиво? Можно написать скрипт, который при перезагрузке будет создавать диск в памяти с помощью mdmfs и копировать на него данные, но это костыль какой-то.