Vitaly Karasik

Решено.
Оскам меняет время на предыдущее. Очень мудро было закомментировать WARNING в исходниках.

https://github.com/gfto/oscam/blob/2780c48789c8e14...

#if defined(CLOCKFIX)
if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)){ // check for time issues!
lasttime = tv; // register this valid time
}
else
{
tv = lasttime;
settimeofday(&tv, NULL); // set time back to last known valid time
//fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** \n");
}

Ansible, Chef, Puppet, Salt) на выбор

Тут люди подписались, в общем проблема наблюдается только на 5.7
Кардинально помог STRAIGHT_JOIN. Ответ нашелся тут.

Нет никаких годных материалов. Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий.
Переход на DevOps делается в три этапа:
1) Сначала полностью все автоматизируется. По поводу доставки кода вопросы врядли возникнут - Jenkins и Maven известны даже детям. Ну не обязательно они. У каждого языка свои инструменты. gradle, grunt, waf... Но автоматиризровать надо все, включая деплой SQL (LiquidBase, dbMaintain, sqitch и т.д.). Эта часть освещена очень хорошо в интернетах.
2) Затем убираются все боттл-нэки в работе админов и программистов. Например внедряется Green/Blue-деплоймент. В точках деплоя собственного ПО средства провиженинга (puppet/ansible/chef) заменяются на средства деплоймента (uDeploy например). Устанавливается мониторинг и логирование. На все это тоже есть свои инструменты (Sensu например).
3) Начинается работа с людьми - вовлечение программистов в ответственность за результат на стороне Ops и вовлечение сисадминов(operations) в результат на стороне Dev (подгон под FHS и все такое). Ключевой момент в том, что людям придется понять, что их ответственность приходит эхом оттуда, где они своими руками не трогали (для этого даже автоматически создают новые энвайронменты всякими докерами и вагрантами). Закоммитил кривой код в IDE, не учел зависимость в пропертях, поправил конфиги не для всех энвайронментов - будешь отвечать и за статический анализ кода и за проваленные интеграционные тесты и за неудачный деплоймент. В обратную сторону тоже самое. Тогда люди начнут действовать по стандартам и настанет искомый результат.

Ну и само собой надо найти сильного релиз-инженера. Потому что DevOps - это не "построил и ушел". Кто-то должен все время смотреть за новыми организационными проблемами и чтобы транк не попал на UAT, например, а на SIT ушел тот же тэгированный код, которому на DEV провели smoke-тесты, а не обновленный парой вредных коммитов, набежавших за время смоука.

Сначала скажите, как звучит конечная задача и что из этого уже есть и чего нет. Может чего детальнее посоветую.

Всем спасибо за помощь и советы!

Было сделано сразу две манипуляции способствующие решению проблемы. Какая из них решила проблему точно уже не скажу.

У Битрикс есть таблица с купонами скидок каталога, в ней у нас было 300 тыс. купонов. Так как изменить запрос нет возможности из-за его системности и обновления Битрикс все затрут, то были проведены тесты с данными. Удаление из таблицы 200 тыс. старых купонов позволило ускорить медленный запрос с ~1.3 сек. до 0.01 сек. В таблице осталось 60 тыс. купонов.
Будем дорабатывать систему автоматической очистки купонов и писать обращение в Битрикс с просьбой оптимизации запроса. Хотя медленный запрос по данным мониторинга и отрабатывал ~3.7 раз в секунду, но это не мешало ему душить процессор.

Второе мероприятие это переход с mariadb (10.1, 10.3 - обе версии тестировались по несколько дней) на percona 8. Предположение пало на проблему базы данных с нашим набором данных и запросами, была мысль, а вдруг в перконе знаю и устранили ошибку.

Я все же полагаю, что ключевой фактор тут был указанный Vitaly Karasik на медленный запрос.
Видимо на наших данных этот запрос вызывал блокировки и высокую нагрузку на CPU из за повышения значений метрик RW Locks S OS Waits, RW Locks X OS Waits, RW Locks S Spin Rounds, RW Locks X Spin Rounds. Купонов становилось больше и в какой-то момент времени их кол. стало критичным для запроса.

Плавающий LA независящий от количества запросов к базе данных оказался влиянием вызова заданий по крону на выгрузку в яндекс маркет каталогов. Буду привязывать отображение заданий агентов Бирикс (крон задачи) на графиках, чтобы в будущем более явно строить связи нагрузки и работу приложения.

UPDATE 09.08.2019

Базу данных вернул на mariadb 10.3. Выяснился еще один запрос повышающий нагрузку на CPU. У нас около 1 млн. сессий в база данных. Так вот Битрикс в методе Sale\Fuser::getIdByUserId($ID) получения одной записи не выставляет лимит и еще и сортирует всю выборку. Если передается FALSE, то он сортировал в нашем случае около 1 млн. записей + добавлял туда каждый раз еще 1 запись. Обращение в Битрикс отправлено, они его приняли и судя по всему скоро будет выпущено обновление.
Кому нужно решение сейчас - измените метод прямо в ядре Sale\Fuser::getIdByUserId таким образом.

$res = FuserTable::getList(array(
                       'filter' => array(
                               'USER_ID' => $userId
                       ),
                       'select' => array(
                               'ID'
                       ),
                       'limit' => 1, // Добавить лимит
                       // 'order' => array('ID' => "DESC") // Убрать эту сортировку
               ));

В первом pow не та степень.

Есть такая "бурчательная" соцсеть, на нытьё в которой компании реагируют очень остро - Twitter. На грамотном английском напишите твит о свой проблеме, в котором упомяните @Hetzner_Online и посетуйте на то, что придётся уйти к другому хостеру. Не исключено, что в скором времени вам напишут или реплай или сообщение в директ с обещанием разобраться. Если не откликнутся или таки не разберутся, просто уходите к другому хостеру.

import string

text = "[('Тестовый текст,)]"

result = ''.join(c for c in text if c not in string.punctuation)

или более производительный вариант

t = str.maketrans('', '', string.punctuation)
result = text.translate(t)

В процессе выяснения деталей в комментариях к вопросу было найдено решение.

В данном случае синхронизация выполнялась без использования опции `--times`, которая сохраняет время модификации файла при синхронизации. При этом не была использована опция `--size-only`, благодаря которой файлы с одинаковыми размерами считаются одинаковыми вне зависимости от времени изменения.
И получается, что даты изменения у всех уже синхронизированных файлов отличаются, и rsync при повторном запуске считает эти файлы потенциально разными и считает их контрольные суммы, чтобы сравнить их по содержимому. На это и уходило время.

Добавление опции `--size-only` существенно сократило время анализа файлов перед началом передачи.
Хотя, на мой взгляд лучше вместо этого по умолчанию всегда использовать `--times` (в том числе в составе `-a`), если возможно.

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