Онтарио, ну вот ограничишь соединения, а скрипт перестанет запускаться после этого?
попробуй комбинацию правил в iptables connlimit и ip назначения того сервера.
может быть лучше программно что-то придумать типа глобального таймаута: если пошел 504, то все копии должны остановиться и обождать.
да ладно? как измерял память израсходованную на соединения?
если узнать какая именно память наиболее расходуется, можно предложить меры.
И ты же понимаешь, что это все живые пользователи? возможно, эти меры ухудшат качество сервиса
websin2011, водка - плохо. особенно до 5 утра.
обязательно помогу вам с репутацией чуть попозже.
(wi), если потыкаешь в настройках дле и включишь полнотекстовый поиск, то тексты автоматически станут разбиваться на слова и таких глупых совпадений не будет.
будут другие проблемы, но может тебе так больше понравится. например, слово "нас" не проиндексируется, потому что слишком короткое. так ведь оно по сути мусорное.
относительно чего быстро? set хранится как набор битов. индекса, который локализует выборку записей с конкретным свойством по нему не сделаешь.
websin2011, я нашел DLE. полнотекстовый индекс там создан все 4 поля, по которым делается поиск.
все, что я предположил оказалось правдой.
CREATE TABLE dle_post( .. short_story TEXT NOT NULL, full_story TEXT NOT NULL, xfields TEXT NOT NULL, title VARCHAR(255) NOT NULL, .. FULLTEXT INDEX short_story (short_story, full_story, xfields, title),
Тебе я порекомендую изучать mysql. Многие вещи там сделаны вопреки реляционной алгебре.
И текстовый поиск и создание индексов на memo удивительным образом работают в mysql.
на самом деле в 5.3 изменили механизм работы сборщика мусора и он может в редких случаях действительно лажать на вроде бы нормальном коде.
попробуйте откатить php до 5.2 или почитайте как вызывать сборку мусора насильно.
start.cmd :
:STARTphp.exe myscript.phpGOTO START
тут GOTO произойдет только если скрипт упал.
Альтернатива - не создавать индексы и надеяться что без индексов выборка тоже будет достаточно хороша.
Другая альтернатива - создавать дополнительные ссылающиеся таблицы.
просто удалить все индексы на поля tinyint и не париться.
Я давно заметил, что вы всегда выдумываете разные вопросы про mysql не имея реальной проблемы. Это непрактично. Порекомендую вам просто генерировать достаточно большие и характерные тестовые данные, а потом уже искать узкие места и плохие запросы.
это плохой выбор индексов с точки зрения экономии места и скорости обновлений таблицы. В индексах хранится каждое значение 0 или 1 для каждой записи.
так что удалить эти индексы и проверить будет ли достаточно индексов bt_FKIndex1, user_id. Мне почему-то кажется, что будет.
Если true в данных полях очень разрежено, то можно каждое булевое поле заменить отдельной таблицей отношений. В этом случае все будет довольно компактно хранится, потому что для 0 используется факт отсутствия записи-отношения.
И где сами данные графиков хранятся? уж не ерундой ли вы себе голову забиваете?
