22 января 2013 г., 19:16 пользователь Oleksii Tsvietnov <[email protected]>написал:
> On 01/22/2013 06:55 PM, Alexander Yerenkow wrote: > >> >> Мне вот что интересно, 24г вроде как мало для таких объемов.. >> >> > Почему мало? Какие расчёты? > Субъективно мало :) Расчётов не дам, но грубо в рассылке мелькают что для отличного перформанса желательно иметь порядка 1Г оперы на 1Т файлов, плюс минус в зависимости от мелкости файлов. Плюс сама ОС что-то кушать должна, нжинкс тот же, пхп. > Добавить то можно по идеи, но нужны какие-то обоснования :) > > > > Дальше, где и как сделан свап? >> >> > swap сделан на двух системных дисках в gmirror'e, 2*ram, на on-board > контроллере. > По графикам мунина, своп использовался ооочень эпизодически и в небольших > размерах. Просто ты не писал про него, на всякий случай уточнил :) > > > И чем мотивирован такой высокий резерв под мета информацию, она что, так >> часто меняется или чтото конкретное такой лимит улучшает? >> >> > ;) Как я и писал, пробовал различные варианты. Те что прислал - просто > последний из тестов, с очередного из блогов, где человек рассказывал как он > тюнил под high load. > Какие можешь посоветовать параметры? Мета информация, это по сути инфа о таймстампе файла, его атрибуты, в общем, как мне кажется в твоём случае абсолютно бесполезная вещь. Я правильно понимаю, что ls не делается, а имя каждого файла хранится у вас в базе, и он отдаётся по нему? Мета в твоём случае разумно будет дефолтную ставить и смотреть как и что. > > > Не думал, если возможно, в логике заливки разделять файлы по пулам, или >> хотя бы по фс в зависимости от их размера, а уже фс подтюнить по размеру >> блока? >> >> > Маловероятно, по крайней мере сейчас, ибо это завязано на логику кода... а > код смотрит на загрузку каждого пула (по самому загруженному диску в пуле) > и принимает решение куда лить файл. Другими словами, есть пространство > пулов, куда можно ещё лить, скольким лить, в зависимости от загруженности > дисков. Сейчас вряд ли будет интегрировано дополнительное дифференцирование > по размеру. > > > Файлы не.в одном катаоге лежат, поделены как-то? >> >> > Есть одноуровневая иерархия из 16 каталогов в каждом пуле. > Т.е. 8 каталогов (точки монтирования zpool), там всего 16 каталогов и в > каждом около 1000 файлов > > > Есть ли возможность сымитировать нагрузку по трафику, если нет, то хотя >> бы записать трафик и проиграть, да глянуть что да как. >> >> > Вот тут немного не понял... > Когда включаются в работу, пулы пустые, диски не загружены, все ломятся > заливать файлы, какие захотят. > Трафик под 800 мбит обычно, и на этом этапе особых проблем я ни разу не > замечал. > Через некоторое время, когда назаливают несколько десятков тысяч файлов, > трафик на даунлоад начинает расти выходя на свой предел и вот тут уже > начинаются проблемы. > > Atime случайно не включился? >> >> > отключен вместе с чексумами, и дедупа тоже нет Если есть у тебя второй серв который имеет к этому гигабитный доступ, то можешь создать поболее файлов из /dev/zero (аналогичное количество и размеры), и покачать их например по ссш, а не по хттп, посмотрел бы как ZFS у тебя реагирует на это, потом по хттп. Проблема думаю таки в памяти или в тюне, надо экспериментировать. > > > > Можно ли получить доступ извне ( например по нда) поглядеть ? :) >> >> > Так пока и глядеть-то не на что. Сервер выведен полностью из работы... ;( > Да и как обосновать это "поглядеть" ;) > Вряд ли. > > -- Regards, Alexander Yerenkow
