Полная Версия: Множественный редирект специально - через PHP или
| Цитата (killer8080 @ 12.12.2016 - 19:37) |
| ты еще забыл про дополнительный мониторинг, в случае аварийного завершения процесса в таблице так и зависнет processing и отвалится твой скрипт, и даже знать об этом не будешь |
| Цитата (TranceIT @ 12.12.2016 - 08:45) |
| А далее как говорится "гуляй рука - балдей писюн". Смотря какая гибкость нужна. |
______________________________________________________________
| Цитата (killer8080 @ 12.12.2016 - 19:37) |
| Я же не предлагаю грузить CPU на 90%, на практике 1-5% достаточно для нормальной работы скрипта, и совершенно безболезненно для сервера. |
Вот тебе конкретная кофигурация VPS от изветного хостера. OpenVZ 7 ГБ 2000 МГц 256 МБ.
Ты уверен что уложишься в порог 5%?
С памятью что делать будешь?
_____________
Безвозмездно помогаю только тем, кто сам пытается что-то сделать.
Остальным за WMR
Даже если там 10 строк кода!
Даже если мне это ничего не стоит!
Даже если вы нуб!
| Цитата (TranceIT @ 13.12.2016 - 10:33) |
| Вот тебе конкретная кофигурация VPS от изветного хостера. OpenVZ 7 ГБ 2000 МГц 256 МБ. Ты уверен что уложишься в порог 5%? |
да, нужно правильно подобрать задержку. Нет разницы что ты снижаешь загрузку CPU постоянными перезапусками кроном, что слипом в самом процессе. В демоне я применял этот метод, там то же было постоянное сканирование ФС, без задержек мой старенький ноутбук уходил в ступор. Это кстати актуально и для крона, если скрипт создаёт бешеную перегрузку, то крон не панацея, станет ли легче от того что сервер будет падать с интервалами запуска по крону
| Цитата (TranceIT @ 13.12.2016 - 10:33) |
| С памятью что делать будешь? |
все решается практическим путём, нужно замерить реальное потребление ОЗУ, если слишком большое - искать пути оптимизации (может вообще на C переписать). В долгоиграющих скриптах нужно заботится о памяти, все переменные с отработанными данными ансетить, следить чтоб не было утечек памяти.
| Цитата (TranceIT @ 13.12.2016 - 10:33) |
| Вот тебе конкретная кофигурация VPS |
конфигурация должна иметь запас "прочности", если сервер загружен под завязку, значит её пора пересматривать и раскошеливаться на железо.
Вообще у нас сейчас спор не о чём. ТС не делал никаких практических замеров, а сразу взялся оптимизировать на всякий случай. Может там и так все нормально работает
| Цитата (killer8080 @ 13.12.2016 - 23:01) |
| ТС не делал никаких практических замеров, а сразу взялся оптимизировать на всякий случай. |
И правильно сделал. Надо отталкиваться не от каких-то мифических цифр непонятно откуда взятых, а сразу писать нормально.
В данном случае задержку использовать нельзя. Любые изменение в нагрузке и значение будет неверным.
_____________
Безвозмездно помогаю только тем, кто сам пытается что-то сделать.
Остальным за WMR
Даже если там 10 строк кода!
Даже если мне это ничего не стоит!
Даже если вы нуб!
| Цитата (TranceIT @ 14.12.2016 - 08:45) |
| И правильно сделал. Надо отталкиваться не от каких-то мифических цифр непонятно откуда взятых, а сразу писать нормально. |
Точно, нужно отталкиваться не от мифических цифр, а от мифической нормы
| Цитата (TranceIT @ 14.12.2016 - 08:45) |
| В данном случае задержку использовать нельзя. Любые изменение в нагрузке и значение будет неверным. |
То что ты разбиваешь задачу на куски и запускаешь с интервалом по крону - это и есть задержка!
С тем лишь отличием что перезапущенный процесс ничего не знает о предыдущем, и тебе приходится лепить костыли с контролем отработки предыдущего процесса, создавать средство общения между разнесёнными по времени процессами в виде
| Цитата (TranceIT @ 12.12.2016 - 10:45) |
| 1) Я бы создал служебную таблицу управления. 2) Разделил бы все таблицы на 3-4 пула и по крону в несколько потоков обрабатывал и записывал результат во временную таблицу постепенно помечая в служебной какие таблицы уже обработаны. Если в железе ограничены - можно на пулы не разделять. 3) Рядом повесил бы скрипт который чистит "мусор". Как только скрипт видит что все таблицы обработаны он начинает скан. 4) Для этого скрипта я бы создал свою служебную таблицу где помечал бы отсканированные каталоги. Либо путем флага если структура каталогов известна, либо путем записи в таблицу. 5) Как только скан закончен - актуализирует данные в основной таблице и сбрасывает параметры в служебных таблицах. |
| Цитата (TranceIT @ 14.12.2016 - 08:45) |
| В данном случае задержку использовать нельзя. |
| Цитата (GET @ 9.12.2016 - 18:25) |
| по результатам он обновляет эти таблицы, удаляет картинки, возможно разный файловый мусор (это самое тяжелое - скан множества каталогов). |
sleep в цикле обработки каталогов - это единственный способ снизить нагрузку на I/O, крон эту проблему в принципе не решает, он лишь дробит перегрузку, растягивая мучение на очень большой период.
| Цитата (TranceIT @ 14.12.2016 - 08:45) |
| Любые изменение в нагрузке и значение будет неверным. |
к фатальным последствиям это не приведёт, в любом случае ничто не мешает сделать скрипт адаптивным, анализировать текущее состояние системы из скрипта и подстраивать таймаут.
Здесь расположена полная версия этой страницы.