Всем привет.

Прошу откликнуться знатоков.

Есть большущий объем тумбов (преъевью картинок) на сервере, порядка 500Гб.
Сейчас размер их не устраивает. Написал скрипт который обходит папки и работает с картинками из папок thumbs.

Сам скрипт работает нормально.
Прошу дать советы как не повесить моим скриптом сервер.
Использую в данный момент sleep, но может лучше повесить на крон?
Так же рад любой помощи в оптимизации кода, да бы ускорить процесс обработки тумбов.




Это сообщение отредактировал(а) gvoksel - 10.8.2010, 21:22

а разве, это не разовая работа?
выполняешь по этапно в несколько приёмов и всё. зачем тут крон? можешь и вручную несколько раз запустить

Боюсь сервак повесить. Хотя оригинал тумбов не сильно большой.

Что понимаешь под словами поэтапно? 

Написал обычную рекурсию по каталогу

Результаты следующие: 

на рекурсии 10000 файлов - Скрипт отработал за 141.309851 секунд
на итераторе 10000 файлов - Скрипт отработал за 151.990946 секунд


как бы узнать повешу ли я своим скриптом сервак   
на моем компе =) четырех ядерка правда - ни капли подвисалок + set_timelimit (0)



Это сообщение отредактировал(а) gvoksel - 11.8.2010, 14:33

Я бы удалил всё с концами, а новые генерил бы по требованию и сохранял бы.
500 ГБ, это при условии что средняя тумба не более 10 кб. Ужас....

Так не получится. сейчас все тумбы задействованы. Если все удалить. Считай каталог с фотами слетит..так что не выход это(

Они же задействованны не одновременно же?
Картинки отдаются nginx?
Если да, то примерно так 

Но если не нравится этот вариант, тогда свой скрипт запускай ночью со слипом секунд в 10.

--

Что-то я прикинул так, 500гб/15кб~30млн тумб 
на 10т уходит по 150 секунд, тогда на 30 млн уйдет 138 часов. Что-то мало верится что столько скрипт отработает без сбоев.
Либо мой вариант, либо в крон пихать.

IgorIV, спасибо.

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

структура такая

корневая папка
   - год-месяц
       - тумбы
   - год-месяц
       - тумбы

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

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

Да уж. А потом окажется что такие размеры тоже не устроят.  Может все таки пойти другим путем?
1. Тумбы выводить в див нужного размера бэгграундом.
2. Если получится можно указать размеры тумбов прямо у тегов.
3. Перезаписывать тумбы по мере обращения.
4. Переубедить начальство что это самые оптимальные размеры для тумбов.
5. Не бояться начальства и высказывать свою точку зрения.

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

Это сообщение отредактировал(а) capitan - 12.8.2010, 11:37

ksnk,  спасибо уже почти сделал.


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

Сейчас как раз токи реализовано, что картинка выводится в меньшем масштабе, чтобы подгонялось по пда версию. 
После работы скрипта вес тумбом страниц должен уменьшится почти в половину ~ с 13кб до 6кб на одну тумбу.

А то что касается окончательных размеров, думаю они все таки окончательные  

Это по воде вилами ...

А вот это интересно, поделиться можешь или коммерческая тайна?

В нескольких последних проектах, подразумевающих перманентный процесс, создающий критичную нагрузку, проверял load average. Т.е., к примеру, лимит кол-ва процессов проксичекера = const / текущая нагрузка, пересчитывался раз в 10 секунд. Ну или интервал для sleep в вашем случае.
А вообще, насколько понял, задача не требует запуска в контексте веб-сервера, посему лучше запускать с минимальным приоритетом (nice) в CLI-контексте.

А генерировать thumb по требованию не? Я не думаю, что пользователь сильно расстроиться, если прождет загрузку страницы на две секунды дольше.

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

Ну или ночью подключай тогда.

Ну вы проблему придумали. Подвесить сервер... 
Пишешь шелл скрипт, который обходит твои каталоги и конвертом имиджмейджика делает то, что тебе нужно.
Проверено на полуторатерробайтных серверах забитых 1-10мб картинками.
А вообще - генерация по требованию: наш выбор.