Подождите, но в момент формирования и загрузки файла - дата создания ноды ведь еще неизвестна? А пути деривативов формируются уже потом из пути загрузки файла.
----------------------------
Ага! Разобрался. В момент загрузки файта он еще в tmp находится, а переносится в рабочий каталог уже при сохранении, так что работает img/[node:created:custom:Y]/[node:created:custom:m]
Все верное здесь написано. Только у меня вообще ерунда какая-то. Вернул все обратно (дурная голова рукам покоя не дает) и сумел найти момент ошибки. При создании материала деривативы создаются. Однако в какой-то момент пропадают.
На сайте установлена запись файлов в каталоги вида [current-year]/[cuurent-month]/[current-day].
Так вот. При создании материала, к примеру, дериватив создается в каталоге 2019/12/23/img.jpg
В общем плюнул на это дело. Написал модуль, который перед выводом ноды проверяем на битые ссылки и если что - кэш сбрасывает. После НГ займусь плотно, если само не рассосется )
Постоянного мониторинга нет. Но в режиме реального времени если наблюдать, то с большим запасом железо.
8 ядерный проц. В среднем показывает load average: 1.35, 1.15, 1.16
Файл подкачки пустой. Памяти с избытком. С дисками всё в порядке. Под базу SSD используются.
Самое неприятное - логи пустые (криминала в них нет). Друпал чистый без вмешательств и патчей.
Понятно всё. Но у меня на сервере памяти с избытком. Самое узкое место - процессор, так скажем, или алгоритм работы солр хромает, который я править не собираюсь естественно.
Кстати, раньше использовался сфинкс - вот он летал. Реально. Но по некоторым техническим причинам пришлось на солр перейти. А вообще - сфинкс всем рекомендую. Классный движок.
У вас проблема в нехватке ресурсов на сервере и апач там самое жрущее звено
Похоже, я косноязычен и не могу внятно объяснить свою проблему. На сервере работает поиск solr - перегруженный всякими фишками. Поиск тормозит работу всей системы. Бывает редко, но метко - поиск перестает справляться с количеством запросов. Его надо отключать в такие редкие счастливые моменты.
Ну написал же. Нет денег на еще сервер. Моя бы воля - я бы вообще все по серверам раскидал и балансировщик прикрутил.
Да. Надо тупо сообщать, что не работает. Но не могу же я сам сидеть и следить за статусом апач и сообщения слать?
На мой взгляд, выжато все до предела. Даже кэширование esi для авторизованных через varnish настроено. Проблема, что поиск реально сложный, внутри него много всяких обработок + нечеткий поиск и прочие плюшки сделаны. А записей на сайте более миллиона.
UPD Я не правильно понял вопрос. Нет, железяку помощнее не получается. Как медвед говорил - денег нет, но держитесь там.
Не всегда создаются кэшированные изображения
И в общем да. Наверное вся собака порылась, что я неверно токены в пути файла указал - привязался к текущей дате. Бывает (
Спасибо за подсказку! С наступающим НГ!
Не всегда создаются кэшированные изображения
О! Точно!
Подождите, но в момент формирования и загрузки файла - дата создания ноды ведь еще неизвестна? А пути деривативов формируются уже потом из пути загрузки файла.
----------------------------
Ага! Разобрался. В момент загрузки файта он еще в tmp находится, а переносится в рабочий каталог уже при сохранении, так что работает img/[node:created:custom:Y]/[node:created:custom:m]
Не всегда создаются кэшированные изображения
Спасибо всем за участие в теме!!!
Все верное здесь написано. Только у меня вообще ерунда какая-то. Вернул все обратно (дурная голова рукам покоя не дает) и сумел найти момент ошибки. При создании материала деривативы создаются. Однако в какой-то момент пропадают.
На сайте установлена запись файлов в каталоги вида [current-year]/[cuurent-month]/[current-day].
Так вот. При создании материала, к примеру, дериватив создается в каталоге 2019/12/23/img.jpg
Есть ли у кого-нибудь решение?
Мощно! Уважаю.
Не всегда создаются кэшированные изображения
И всё же решение нашлось. Поставил imagemagick вместо GD. Обидно только - причину не определил. Но пока уже сутки все нормально.
Не всегда создаются кэшированные изображения
В общем плюнул на это дело. Написал модуль, который перед выводом ноды проверяем на битые ссылки и если что - кэш сбрасывает. После НГ займусь плотно, если само не рассосется )
Не всегда создаются кэшированные изображения
Постоянного мониторинга нет. Но в режиме реального времени если наблюдать, то с большим запасом железо.
8 ядерный проц. В среднем показывает load average: 1.35, 1.15, 1.16
Файл подкачки пустой. Памяти с избытком. С дисками всё в порядке. Под базу SSD используются.
Самое неприятное - логи пустые (криминала в них нет). Друпал чистый без вмешательств и патчей.
Не всегда создаются кэшированные изображения
Воспроизвести не могу. Появляется не очень часто. Может быть 2-3 раза в день.
Смотрел во всех логах - апач, мускл, сислог... Ничего криминального не нахожу.
Не всегда создаются кэшированные изображения
Да. Извините, если неясно выразился
Отключение поиска под нагрузкой
Все верно. Давно уже сделано. В общем-то весь tmp в tmpfs смонтирован.
Отключение поиска под нагрузкой
!!!! Спасибо нашел. /etc/default/solr.in.sh
Отключение поиска под нагрузкой
У меня solr в настройках 2Gb. Хватает с избытком
Отключение поиска под нагрузкой
Да. Так, наверное, будет красивое решение.
UPD И да, я понимаю, что с большой долей вероятности, я джаву с солр неправильно настроил, но пока разберусь... много времени может уйти.
Отключение поиска под нагрузкой
В жаву не совался. Буду смотреть. Если подскажете - буду признателен.
Отключение поиска под нагрузкой
Можно и так, но таймаут не лучшая идея на мой взгляд. Юзеров будет напрягать. Лучше не доводить до крайностей.
Отключение поиска под нагрузкой
Понятно всё. Но у меня на сервере памяти с избытком. Самое узкое место - процессор, так скажем, или алгоритм работы солр хромает, который я править не собираюсь естественно.
Кстати, раньше использовался сфинкс - вот он летал. Реально. Но по некоторым техническим причинам пришлось на солр перейти. А вообще - сфинкс всем рекомендую. Классный движок.
Отключение поиска под нагрузкой
Там процессор тупо не успевает. На сервере 64 ГБ оперативки, установлены твердотельники.
Отключение поиска под нагрузкой
Похоже, я косноязычен и не могу внятно объяснить свою проблему. На сервере работает поиск solr - перегруженный всякими фишками. Поиск тормозит работу всей системы. Бывает редко, но метко - поиск перестает справляться с количеством запросов. Его надо отключать в такие редкие счастливые моменты.
Отключение поиска под нагрузкой
У меня проблема не в скорости обработки скриптов, а в скорости работы поискового сервера.
Отключение поиска под нагрузкой
И еще, кроме сервер статус, как нибудь можно получить количество "requests currently being processed" безвключения этого самого серверстатус модуля?
Отключение поиска под нагрузкой
Не смог найти, server status парсить надо, или есть какой-то способ что нибудь типа json получить?
Отключение поиска под нагрузкой
Ну написал же. Нет денег на еще сервер. Моя бы воля - я бы вообще все по серверам раскидал и балансировщик прикрутил.
Да. Надо тупо сообщать, что не работает. Но не могу же я сам сидеть и следить за статусом апач и сообщения слать?
Отключение поиска под нагрузкой
На мой взгляд, выжато все до предела. Даже кэширование esi для авторизованных через varnish настроено. Проблема, что поиск реально сложный, внутри него много всяких обработок + нечеткий поиск и прочие плюшки сделаны. А записей на сайте более миллиона.
UPD Я не правильно понял вопрос. Нет, железяку помощнее не получается. Как медвед говорил - денег нет, но держитесь там.
Как бороться с вирусом на drupal (код внутри)
поищите по строке
grep -rwn /var/www/ -e 'eval(String.fromCharCode'
Как просканировать чужой сайт на файлы, которые можно взять?
Если не ошибаюсь, в лоб это не решается. Есть инструменты типа https://olivier.sessink.nl/jailkit/
А вообще - странно. Нужная, вроде, функция.