ну, это я знаю. как-то ддосили и логи заняли место, геморроя было много)
я спрашивал именно про диски что не под систему.
Подумайте сами логически, если закончится место на диске то что может произойти?!
Если человек установил Linux или взялся за его админство использование, то он банальные вещи при заполняемости диска должен знать!
мне использовать свободное место до упора? и чем это чревато?
Ничем, просто место закончится и все.
+- 4-7% в минус можно будет уйти, у системы есть резервируемость еще.
Попробуем обновить битрикс до последней версии стабильной, накатим php 8 / mysql 8.
После отпишусь.
Значит конструкция БД неудачная. И теперь надо или её переделывать или жить с этим. Кэши всякие там, разбивать на отдельные запросы без JOIN.
Да вот же, руководству говорю что нужно избавляться от join запросов без индексных, это может снизить нагрузку сервера до 50%.
Но видать это дело затратное и руководство не спешит решать эту проблему.
Тесты тесты и ещё раз тесты. Какие могут быть места узкие если innoDB pool достаточный и диски SSD
Попробуем как нибудь по умолчанию innodb_thread_concurrency = 0.
При join выборок куча таблиц создается, а так же много joiun без индексно почему то используется.
Рекомендую переезжать на более современную SQL или последнюю MariaDB или MySQL8. Это чтобы быстрее работало всё.
А этот параметр лучше не трогать, ибо может снижаться производительность: https://www.percona.com/blog/2016/03/17/percona-server-5-7-performance-improvements/
Одна Pecrona что-то там сделала, чтобы у них этот параметр работал нормально, сама Mysql забила на него. Но 5.7 в любом случаи устарела.
Даже в старых темах: https://dba.stackexchange.com/questions/81204/hyperthreading-mysql-innodb-thread-concurrency-performance
Везде пишут, не трогать этот параметр. Никакой скорости он не прибавит.
Я лично не трогаю его и не настраиваю своим клиентам. Также и innodb_buffer_pool_instances не настраиваю. Он по умолчанию работает как надо.
При штатной, нормальной работы базы думаю по умолчанию подойдет innodb_thread_concurrency.
Но когда есть моменты кривых/тяжелых запросов, без ограничения innodb_thread_concurrency создаст узкие места процессора и диска.
Мое мнение.
Допустим что на join запросах индексы не могут быть использованы, как тогда уменьшить нагрузку?
Это понятно.
Вроде программист сказал что индексы там есть.
А вот это уже означает что проблема с сертификатом.
Невозможно получить сертификат локального эмитента. Возможно, сертификат сайта или промежуточные сертификаты установлены некоррекно.
Не проще просто переделать сертификат.
