- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Нужно настроить имеющуюся базу данных на максимальную производительность.
Несколько дней назад объем базы превысил объем RAM сервера (16Gb), база стала сильно тормозить
Конвертация больших таблиц из MyIsam в InnoDB не помогла справится с тормозами, по ощущениям тормозить стало больше, объем базы стал 34 гб. Возможно поможет лучшая настройка конфига. Задача выявить причину тормозов и ликвидировать их. ОС CentOs 4.4 64-bit
Сервер самый быстрый из возможных.
Жду предложений только от специалистов, имеющих опыт в решении подобных задач. Способных выполнить задачу быстро и качественно. Репутация также имеет значение.
ICQ 630945 - стучитесь, я всегда в онлайне.
Отписал в ICQ.
Сервер самый быстрый из возможных.
Самое кошмарное заблуждение многих современных "разработчиков": можно писать и проектировать как попало, потом взять сервер по-мощнее и всё будет летать. Надеюсь, к вам это не относится, но на всякий случай спрошу...
Вы уверены, что вам нужен специалист именно по mysql/innodb, а не по проектированию самой БД?!
Самое кошмарное заблуждение многих современных "разработчиков": можно писать и проектировать как попало, потом взять сервер по-мощнее и всё будет летать. Надеюсь, к вам это не относится, но на всякий случай спрошу...
Вы уверены, что вам нужен специалист именно по mysql/innodb, а не по проектированию самой БД?!
знаете, это уже совсем флуд и оффтопик... если уж пошло на то, проект для Oracle/MsSQL :)
MySQL идеален для таблиц в районе <1 Gb, в этом случае он показывает действительно лучшую производительность.
Когда объём базы вырастает - начинаются совсем другие проблемы и вопросы.
А не написать нам вместо скрипта-клиента,который делает..., триггер?А нельзя ли некоторые таблицы выгрзить в оперативную память с репликацией на резервный сервер?
Там поможет грамотная разработка БД и разнесение базы на несколько серверов
А тормозить стало вероятно потому что превысили оперативку и оно полезло в своп.
Тут конвертации не помогут - если индекс перелазит в своп, то не все ли равно в каком он формате лежит на диске?
Ну так чем закончилось? интерес разбирает просто... на лечение к программистам или куда?
ps. или программистов на mysql.com/doc ?
зря вы конвертировали,
в доке же написано, что InnoDB медленнее MyIsam из-за того, что там включена поддержка транзакционности.
нужно смотреть схему базы, а потом уже делать выводы, так что ищите грамотного DBA, который знает MySQL
Структуру дадите посмотреть?
зря вы конвертировали,
в доке же написано, что InnoDB медленнее MyIsam из-за того, что там включена поддержка транзакционности.
а еще в доке написано, что у myisam локинг на уровне таблиц при операциях записи...
а еще в доке написано, что у myisam локинг на уровне таблиц при операциях записи...
доки рулят:)
я не DBA, поэтому рекомендую ТС найти грамотного спеца по MySQL
я не DBA, поэтому рекомендую ТС найти грамотного спеца по MySQL
который, исходя из текста предложения, ликвидирует его программистов?
2ТС: мы все во внимании... готовы ставить пиво за оглашение причины.