На gmail даже уведомления от систем мониторинга, которые уж точно ничего не продают попадают в спам. По-моему это анализ поведения пользователя: зачастую эти системы начинают сыпать не очень критичные ошибки, которые администраторы длительно игнорируют. Хотя там еще и ссылка есть.
Все про ту же. Все уже написали. Три человека про одно и то же твердят.
Ищите решение проблемы не в смене способа хранения и работы с данными, а в переосмыслении алгоритмов и структуры.
Ну вот поставите вы 3 сервера для nosql-хранилища и отдельный для memcache. Что-то там распределите. Но работу по поиску они примерно ту же будут выполнять. И сколько еще их вы сможете поставить, даже при линейном росте производительности ? Это при любом раскладе невыгодно.
sidorka, так я и написал куда. Короткий ответ : смотреть на себя и в предметную область.
Не надо думать как математик. Ответа на такой вопрос нет. Никакая база не может являться "сферической в вакууме". Программисты и инженеры решают частные практические задачи.
В реляционной теории sql-базы ведь возвращают ответ как бы мгновенно. Абстракция sql считает, что план работы запроса отсутствует как предмет обсуждения. Но он существует и влияет на реальность.
Применение Percona не сделает вашу базу автоматические быстрее. Это все тот же самый код mysql с дополнительной диагностикой. Ей нужно уметь пользоваться и думать.
Факты, которые вы храните в базе в крайне больших масштабах создаются автоматами. В какой базе их не храни - быстро они не станут обрабатываться никак. Уже понятно что стоимость их хранения несоразмерна с вашей выгодой.
Выбор максимума из большого списка, подсчет суммы - это все агрегация и она не оптимизируется никак. Только если эту работу сделать заранее.
Например, незаслуженно забытый вебмастерами openx просто не хранит отдельные факты о кликах и просмотрах в бд . Действительно не хранит, но выполняет свои задачи по оценке CTR и лимитированию показов по разным факторам.
Как ? Он предагрегирует данные. Хранит клики и просмотры за час. Если там какие-то условия - пересчитывайте правила показа не на ходу, а в некоторые промежутки. Ужасно подробная детализация не нужна. Измените условия. Даже откажитесь от определенных вещей, обещанных пользователями, которые вы считаете плюсами и фишками - и она заработает быстрее.
Вот что на самом деле является оптимизацией приложения.
это сейчас о чем было ?
Они знают когда именно какая лицензия куплена.
Скорее всего все будет работать, но обновляться перестанет через год.
Разумеется. В таблице ARP с этого интерфейса что-то запомненное есть ? Надо чтобы было.
Как долго это продолжается после момента переконфигурирования ? Может быть просто сбросить кеш роутинга и arp заодно ?
Зачем здесь вообще какие-то группы, если приходит l2tp-трафик, путь прохождения которого уже невозможно разделить ? Может вторая группа поэтому и пуста?
Остальное не читал - пусть цисководы привыкают разговаривать не конфигами, а словами. Тем более, что конфиг l2tp вроде как не нужно рассматривать и он вообще не полный.
Вообще-то это VPS. Это видно по названию устройства диска vda.
Соответственно, там есть соседи . Делать какие-то измерения и выводы по одной-двум картиночками нельзя.
Раз у вас есть atop - настройте чтобы он записывал в файл историю и покрутите во времени.
А не факт, что там что-то неправильно настроено. Я думаю, там просто cp1251 используют и никто не задумывался зачем и почему. В правильно настроенной cp1251 ci все равно будут различаться Е и Ё. Выбрать какую именно силу сравнения использовать в mysql нельзя. Ее однажды уже выбрали разработчики.
Настройка своей специальной collation для cp1251 совсем не тривиальна и потребует своей копии mysql-сервера.
Я предлагал просто базу в utf8 перевести. А там само все исправится. По крайней мере для Ё и E.
Исходя из возможности это сделать уже и нужно выбирать решение.
а зачем думать, если сайт прибылен и никто на кодировки никогда не жаловался ? Это ли не мечта всех сеонизаторов?
А у многих нет проблем. Пока они не прочитают этот топик и не начнут думать, что есть .
