- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
и лимит на подключения быстро исчерпается
ну.
10 символов
myhand, но вопрос не в них, а в том какие еще веселые баги вы увидите при попытке ограничить mysql - на длительное время подвиснет выполнение запросов этого пользователя (эта ошибка временная) и лимит на подключения быстро исчерпается. А если сервер для "исправления" перегрузить, то и таблицы попортятся.
Короче, не вариант это.
Так есть же лимиты на подключение per user. Не слыхали разве?
Впрочем не спорю - может есть еще какие нетривиальные проблемы с подобным вариантом. Придумал его даже не я собственно - где-то в рассылке *mysql рекоммендовали ихние лучшие собаководы. Авось не посоветуют плохого...
А бинлогов не бойтесь - они не тормозят, так как запись в них последовательная и буфферизируемая. C другой стороны, на хостинге с бинлогами, можно восстановить данные в любой момент, а не только на момент создания резервных копий.
Как правило, я бинлоги включаю на всех серверах (под выделенные веб-проекты, не виртуальный хостинг) именно по этой причине. Тем не менее, небольшое уменьшение производительности наблюдаетеся (в пределах нескольких процентов). Может потому их и не включают на БД виртуальных хостингов, да они еще и место жрут (сравнительно дорогое - SCSI или SAS). Предоставляли бы бекап регулярный - и то хорошо.
да бред это все.
вот следящий за размером баз демон - это еще куда ни шло : http://lrem.net/software/mysql-quota-daemon.xhtml
да бред это все.
Ну, конечно, - Вам виднее...
local123, mysql запускается из под пользователя mysql и квота закончилась у этого пользователя.
надо както по другому проврять квоту для mysql наверное.
а квоты для группы пользователя?
// ключек -g если правильно помню
а квоты для группы пользователя?
// ключек -g если правильно помню
local123, я не понял, у вас mysql за два дня так и не заработал? судя по графику, он продолжал работать после пика. если заработал, какая нафиг разница, что СЕЙЧАС показывает программа quota.
local123, я не понял, у вас mysql за два дня так и не заработал? судя по графику, он продолжал работать после пика. если заработал, какая нафиг разница, что СЕЙЧАС показывает программа quota.
Я искренне благодарен за такое внимание моей проблеме.
Если разложить все по полочках, то получается следующее:
-Упал мускул
-Система мониторинга ISPManager подняла его
Если подробнее рассмотреть проблему, то: На сервере Debian 5, ISPManager Pro, включена опция учета размера баз мускула. В нескольких юзеров закончилось свободное место на диске.
Вы здесь немножко подискутировали, и я не могу понятий следующего:
1) Мускул упал потому что закончилась квота дискового пространства в юзера?
2) Что за скачек на графике? Что означает данный график, это увеличилось количество процессов (потоков) мускула?
3) Как мне быть дальше с такими падениями?, Они и раньше били, и будут продолжаться, так можно базы вгрохать
4) Отключение опции учета размера БД в ISPManager теоретически решит проблему падения сервера БД?
5) Как быть если я хочу учитывать размер БД в квоту юзера?
вероятно, потому что квота для пользователя mysql каким-то образом тоже оказалась включена.
либо ispmanager действительно уже использует предложенный тут хак с групповой квотой и специальным атрибутом в папке. Получается, неудачно использует.
поскольку ошибка временная, спящие потоки mysql ожидали, когда наконец вы почистите диск. когда число их достигло, 400 новые подключения перестали обрабатываться.
в общем случае не верить в ISPmanager и делать низкоуровневые операции самостоятельно.
похоже на то. если что-то работает не так как нужно, логично это отключить.
но так до конца и не ясно, что привело к нехватке места для mysql.
специальный демон, ссылку на которого я давал выше, сможет максимально безопасно для данных все разрулить, хотя и с некоторой погрешностью.
можно еще поныть у них на форуме http://forum.ispsystem.com/ru/showthread.php?t=8542