IKStantin, причем, насколько я видел, это настроенный на php7.4 CentOS, хотя уже с 1 февраля Битрикс пафосно объявил, что пых ниже 8 поддерживать не хочет. Тут не то что "не торопитесь", тут "на хрена козе баян?!". Хостер-то мой - напрочь сертифицированный партнер того Битрикса и вроде бы уверенно его умеет.
Впрочем, на моем интранет-сервере еженощная бэкап-копия этого Битрикса шевелится себе и верно служит мне для экспериментов и разработки. И в Докере я его под php8 поднял для постепенного перевода на эту версию. Но повторять такие эксперименты на боевом сервере, да с таким киндер-сюрпризом, как Битрикс - слуга покорный...
GavriKos, опять же - не те данные. Если бы они шли монотонно и часто повторяясь - да, тут наложение 4 из 4 позволило бы считать поменьше. Но у меня чаще всего будет 1-2 из 4, которые ничего не дают. Ну, 0 из 4 тоже довольно вероятен... но все равно, подозреваю, такая оптимизация больше запутает, чем упростит. И уж на уровне базы, без перебора, точно ничего не позволит определить.
Stalker_RED, в разборе ответа Wataru об этом и говорили.
И вы тоже упустили, что количество нулей нужно не только в новой строке, но и в старой тоже.
Впрочем, вы совместными усилиями навели меня на мысль, что знаменатель для процентов можно считать проще.
Нужно просто вычесть числитель из предварительно высчитанной суммы нулей в двух строках.
И высчитывать значащие биты второй раз (для определения мест, где ноль в одной из строк) не потребуется вовсе.
Да, это надо попробовать!
AUser0, вообще все юзеру система не покажет. А чтобы был лес дочерних, должны быть родители, которые их породили. В моем списке один Апач, и с ключом ps -aux --forest предсказуемо показывает, что ничего дочернего эти воркеры не наплодили.
Vitaly Karasik, да не то чтобы не признают... вроде бы готовы разбираться. Но рефрен "извините за ответ через пять часов, наблюдается высокая нагрузка на ТП" и постоянная ротация ответственного за тикет, в которой, похоже, никто не заинтересован убить лишнее время не то что на решение - даже на знакомство с проблемой.
В результате шаблонную отписку про 40 процессов я вижу в десятый раз в пределах одного и того же тикета.
Сейчас как паллиатив подумываю вынести Лару на VPS (сайт менее критичный, более легкий и простой в обслуживании), оставив на шареде один Битрикс - может, ему и полегчает.
Тариф и так недешевый, а с ТП, которая теоретически может что-то увидеть, бодаюсь уже который месяц без особенного прогресса. Они у себя видят, что все хорошо. Например, мои крон-скрипты у них числятся исполнявшимися.
То, что эти скрипты строго в определенный период (как раз когда я не мог войти по SSH) ничего не сделали и даже не выкинули при этом ошибок, хотя до и после этого периода штатно работают - это уже как бы мои половые трудности.
Вот я как раз непривилегированный юзер, которому ТП вменяет превышение лимита в 40 моих, юзерских, процессов. А я вижу 14 и рассматриваю варианты, что можно сделать в такой ситуации.
Кроме очевидных и деструктивных, разумеется.
Stalker_RED, да без проблем. Вопрос, что это даст.
Сравнение двух 64-битных чисел, например, мне просто НЕ НУЖНО, ни их равенство, ни неравенство ровно ничего не дают.
Wataru, 16 бит должны дать 65536 чисел. Памяти, конечно, немного, хотя Пых еще подожрет...
Да, в нем есть gmp_popcount. Но вызов функции - сам по себе дорогая операция.
В общем, наверное, об этом стоит подумать руками и посмотреть, что выйдет.
GavriKos, я уже писал: количество нулей - 20%-30% в массе. Критической разницы нет.
Впрочем, это позволяет дешево отсечь хотя бы часть данных хотя бы в некоторых случаях - когда в одной из записей менее 95% от нулей другой. Хуже в любом случае не будет.
Да, спасибо, тут вы мне помогли.
Боюсь, тогда задача сократится до "где взять столько памяти". Умножаем десятки тысяч записей на тысячи нулей в них - получаем сотни миллионов записей в этой таблице. Добавляем к этому, что в подсчете нужны все нули не только новой строки, но и сравниваемой, только не сумма, а пересечение... впрочем, это еще можно оптимизировать. Но вот запрос-то к такой базе вы как себе представляете? SELECT record_id, COUNT(1) FROM positions WHERE number IN (тысячи чисел) GROUP BY record_id ? По стомиллионной таблице? Смело...
GavriKos, фокус как раз в том, что количество нулей в строке вообще не играет роли. У двух строк с одним-единственным нулем в одном и том же месте будет 100%, у двух с половиной нулей строго в начале и строго в конце - 0%.
Дмитрий Ярощук, нет, не постарался. Теперь читающий вообще не понимает, о чем речь. Какие-то желуди, какой-то стек и какое-то максимальное качество. Бред.
Wataru, а в чем тогда оптимизация? Только в хранении?
После которого мне нужно будет переводить данные из БД в числа для подсчетов, добавить еще две бинарные операции - и в результате все равно два раза пересчитывать каждый байт-символ. Я не уверен, что на Пыхе это не окажется медленнее того, что уже есть.
Такое ощущение, что код писал человек, а задание - робот.
Стоит перечитать этот выкидыш клавиатуры и по возможности вернуть ему растерянный в процессе набора смысл.
Впрочем, на моем интранет-сервере еженощная бэкап-копия этого Битрикса шевелится себе и верно служит мне для экспериментов и разработки. И в Докере я его под php8 поднял для постепенного перевода на эту версию. Но повторять такие эксперименты на боевом сервере, да с таким киндер-сюрпризом, как Битрикс - слуга покорный...