Дмитрий: там видимо какие то фильтры. если вы хотите что бы запрос всегда отрабатывал с такими условиями oc.`field_id` = 221 OR oc.`field_id` = 248 и учитовал динамические условия
то напишите так
WHERE (oc.`field_id` = 221 OR oc.`field_id` = 248 ) AND (".$where.")";
Dmitry: тем не менее iptables для введения таких ограничений используют, это достаточно распространенная практика т.к. такое решение создаёт минимальную нагрузку на сервер.
Максим Вязников: на https://bugs.mysql.com нет каких то открытых и закрытых вразумительных багов связных с этой ошибкой, ни в свежих ни в старых релизах Mysql, поэтому очень маловероятно, что проблема не в отсутствии места/
я так понимаю срабатывает ограничение IPCCommTimeout но оно срабатывает через 300, потому что проверка состояния процесса происходит каждые FcgidIdleTimeout
есть признаки наличия Suhosin patch к php? этот пач для безопасности придумал дьявал что бы портить жизнь админам =) без него Пхп точно не должен создавать таких проблем, т.к. в силу своей архитектуры он их создать не может (если не написали специальный скрипт для создания таких проблем).
в центос поройтесь в firewalld или у вас его снесли и поставили iptables ?
ваши проблемы возникают на уровне apache-24-worker или фаервола это точно
Dmitry: ну так вы гляньте настройки, те про которые он говорит, где то в /etc/apache что то типа fcgid.conf
там видимо будет и таймаут и ограничение на количество одновременных процессов из за которых больше у вас не открываются новые соединения. httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Mouvdy: редиска легче(меньше, проще, быстрее, понятнее) mysql
хеш таблицы для вас идеальный вариант, они дают время/сложность операций не зависящие от объёма базы. Редиска - это самый популярный вариант хеш таблиц, у вас всё будет быстро и развертывание и работа и бэкапы. Можно конечно взять mysql сделать табличку с хеш индексом, но это странное решение.
Я не очень понял, у вас ещё файлы в этих папках лежат?
прикольный кактус, память то хоть с коррекцией ошибок? как бы память сбоит чаще чем диски, и как бы на порядки чаще. Т.е. после того как база думает, что данные записаны на диск есть вероятность, что данные поменяются. Сброс данных из ОП на диск фундаментальная операция БД, а тут скирдование данных из ОП в ОП, тупо снизили надёжность записи в БД минимум на пару порядков. Чтение не оптимизировали, т.к. на этом сервере явно можно Mysql выделить памяти, что бы и таблицы и индексы целиком поместились в памяти.
coderisimo: Меня это не удивляет, мне иногда приходилось свифтовать для переводов внутри одного банка внутри одной страны. Свифт это можно сказать гарантированная операция, ей плевать на законы, распоряжения цб, санкции и количество денег на счетах т.п. Для международных переводов есть свифт, всё остальные схемы это попытка оптимизировать скорость и/или комиссию. Но эти схемы не всегда могут сработать, а в текущей санационной действительности полагаю они разваливаются каждый день, так что удивляться не стоит.
Просто примите для себя что SWIFT стоит до 50$, переводите суммы побольше и не парьтесь. Парьтесь если сумма больше 50$.
Я не знаю точно, что такое скрилл. Но обычно есть вычет свифта или нет зависит от того оплатил ли его отправитель отдельно (т.е. за счёт отправителя) или его вычитают из суммы (т.е. за счёт получателя).
Может скриллл имеет стчёт в российском банке или прям в альфе и при хорошем потоке переводов в РФ свифтуют один раз и потом раскидывают деньги локально, растворяя эту SWIFT комиссию в своей.
Может ещё, что то нет смысла гадать, т.к. в международные платежи это SWIFT, они для любых сумм с гарантированными сроками и фиксированной комиссией, самые комфортные и прогнозируемые из всего, что существует. Если вы будете ориентироваться на SWIFT т.е. комиссию до 50$ то не будете париться с суммами, сроками, банками, ПС и т.п. это удобно.
