- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Почему не innodb, и там блокировка по строкам идёт автоматическая. Также можно задать максимальное количество памяти для таблиц и всё будет в памяти работать быстро и легко.
Также сброс кэша можно уменьшить через настройки.
Не понял эту фразу. Вы проверяли работу всех индексов?
Также медленно у вас работает чтение или запись без блокировки?
Почему не innodb, и там блокировка по строкам идёт автоматическая. Также можно задать максимальное количество памяти для таблиц и всё будет в памяти работать быстро и легко.
Также сброс кэша можно уменьшить через настройки.
Не понял эту фразу. Вы проверяли работу всех индексов?
Также медленно у вас работает чтение или запись без блокировки?
innodb ставил, но не заметил каких либо изменений.
Я ставил индексы во время SELECT и проверял скорость работы, если индекс ничего не давал, я его убирал.
На SELECT по моему блокировка не влияла
Ничего не давал т.к. запросы в кэше были. Вы кэш очищали, отключали перед тестами?
Если вы делаете выборку по каким-то полям, у вас обязательно должны быть на них индексы.
Это если вы блокировку сделали только на запись. Вы же сами пишете, что блокируете таблицу полностью.
Вы там нахимичили себе на голову всякого, а теперь спрашиваете, что с этим делать. Делать всё по нормальному надо, и блокировка таблицы нужна в ОЧЕНЬ крайних случаях, ну просто в ОЧЕНЬ.
Ничего не давал т.к. запросы в кэше были. Вы кэш очищали, отключали перед тестами?
нет, но кеш долго не держится, так как страница второй раз грузится быстрее в разы (это с кэша), а проходит время и снова медленно.
Если вы делаете выборку по каким-то полям, у вас обязательно должны быть на них индексы.
Да. Это есть уже.
Это если вы блокировку сделали только на запись. Вы же сами пишете, что блокируете таблицу полностью.
Если делаю запись, блокирую таблицу на WRITE, а иначе READ
Вы там нахимичили себе на голову всякого, а теперь спрашиваете, что с этим делать. Делать всё по нормальному надо, и блокировка таблицы нужна в ОЧЕНЬ крайних случаях, ну просто в ОЧЕНЬ.
Это да, но вопрос был про игнор запроса, если он долго идет.
Хотя очень хорошо, что Вы все даете советы не только на конкретный вопрос, а ищите пути решения глобально, не ожидал.
И, если честно, то изначально все было без индексов и блокировок, и усе было плохо, но теперь лишь некоторые ньюансы остались.
Это не имеет смысла. Уберите их.
Переведите всё в innodb, выставите innodb_buffer_pool_size в размер чуть больше ваших таблиц, если они будут пополнятся.
Далее обязательно:
innodb_flush_method=O_DIRECT
и учитывая, что у вас локальные данные, то:
innodb_flush_log_at_trx_commit=0
Кэш лимиты оптимальные, больше не нужно:
query_cache_limit=2M
query_cache_size=128M
query_cache_type=1
И ещё раз проверьте индексы, также индексы могут быть составными и должны быть, если выборка идёт по 2-м и более параметрам.
Это как лечение зубов. Если пациент жалуется, что зуб реагирует на холодное/горячее, то тут или зубную пасту надо менять или зуб сгнил и надо ставить имплантант вместо него. Поэтому надо рассматривать сначала зуб, а потом уже выбирать зубную пасту :)
Переведите всё в innodb, выставите innodb_buffer_pool_size в размер чуть больше ваших таблиц, если они будут пополнятся.
На данный момент самая большая таблица с ссылками занимает 4,3гб, так буфер ставить в 5гб?
---------- Добавлено 16.06.2018 в 14:25 ----------
Переведите всё в innodb
Я было раньше хотел, но
InnoDB также сложнее восстанавливать после сбоя в работе сервера чем MyISAM.
Операция Insert работает быстрее в MyISAM.
Если преобладают операции чтения (SELECT) работает быстрее в MyISAM.
И я тестировал операцию select на обоих типах. MyISAM была быстрее, что важно.
Возможно не оптимально настроен InnoDB
В общем плане работы т.е. комплексной это не так. Долго объяснять. Mysql отказывается от myisam не просто так.
Если на сервере достаточно памяти, то да выставлять 5 ГБ
В общем плане работы т.е. комплексной это не так. Долго объяснять. Mysql отказывается от myisam не просто так.
Если на сервере достаточно памяти, то да выставлять 5 ГБ
Я то попробую, но это не так быстро сделать :)
---------- Добавлено 16.06.2018 в 14:33 ----------
И мой знакомый рассказывал, что у него на сайте была база innoDB, и начало кончатся место. Оказывается в табличке было пару записей, а занимала пару гиг. Он ее перевел в MyISAM и она сразу в несколько сот раз уменьшилась.
И мой знакомый рассказывал, что у него на сайте была база innoDB, и начало кончатся место. Оказывается в табличке было пару записей, а занимала пару гиг. Он ее перевел в MyISAM и она сразу в несколько сот раз уменьшилась.
Ну наверное что-то ваш знакомый не понимал, что перед ним.