- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
myhand, исходники читайте.
или просто подумайте что происходит в обычной программе в случае когда результата очередного выполненного select-запроса в кеше нет, кеш разделен между несколькими потоками и блокировка одна единственная на весь это кеш.
или просто подумайте что происходит в обычной программе в случае когда результата очередного выполненного select-запроса в кеше нет, кеш разделен между несколькими потоками и блокировка одна единственная на весь это кеш.
А почему она *должна быть* одна-единственная? Неужели только мне это кажется багом.
ну сколько можно по третьему разу? да, нужно мерять. но если просят общих советов и их есть у нас.
Ну так "нужно мерять" - тоже общий совет. И более полезный чем ваш - т.к. работает в большем числе ситуаций (а ваша рекоммендация ТС про уменьшение кеша с 60 до 200 скорее всего просто не даст абсолютно ничего ему заметного, исключая смешную экономию памяти).
А почему она *должна быть* одна-единственная?
там все максимально просто сделано. более сложный кеш будет тормозить. он и так уже себя ведет при очистке не ахти как.
в постгресе так вообще нет кеша результатов запросов и им норм.
Неужели только мне это кажется багом.
о, это просто узнать : описываете свое видение проблемы на bugs.mysql.com и получаете статус "вы - лох" (not a bug ).
там все максимально просто сделано. более сложный кеш будет тормозить.
Не уверен. Но да, похоже до сих пор "все просто" (вот совсем недавний статус).
о, это просто узнать : описываете свое видение проблемы на bugs.mysql.com и получаете статус "вы - лох" (not a bug ).
В отличие от - я не лох и сперва поищу уже готовый багрепорт. О чудо, вот результат простейшего поискового запроса:
http://bugs.mysql.com/bug.php?id=37844
Status: Verified
Я запутался, вижу уже уходите от проблем, приводят пример mysql SNP кеша ;)) не реализованного, цитирование блогов , где советуют кеш отключить ;)
P.s На практике было, что mysql кеш создаёт проблемы на сервере, и отключение даёт только положительный результат,соответственно пока изменений кардинальных нет, а значит проблема остаётся.
myhand, можно и поискать, но вы не получите заключения от независимых экспертов конкретно о себе.
Допустим, вы бы запостили точно такой же текст. Это баг ведь не является ничьей ошибкой. Поэтому его за 3 года не исправили и наверное уже не исправят. Тут разницы между Not a bug и verified нет. Verified - менее обидно для клиента. В данном случае сидеть ждать исправления - это самое настоящее лоховство.
На практике было, что mysql кеш создаёт проблемы на сервере
На практике много чего может создать проблемы. Не значит, что обязательно создаст.
И наоборот - на практике много что может принести пользу. В т.ч. и mysql cache.
Решение очень простое: практика; измерения и модификация настроек в соответствии с ними. Никаких "best practices" в виде "отключить кеш нафиг" или "сделать его 64Mb". Неужели все это столь сложно, madoff?
Это баг ведь не является ничьей ошибкой.
Забавно, а технический словарь говорит bug = ошибка, неисправность. Боюсь, только с вашей подачи смысл не изменится.
Поэтому его за 3 года не исправили и наверное уже не исправят.
Мне сложно прогнозировать.
Тут разницы между Not a bug и verified нет. Verified - менее обидно для клиента.
Интересно, а assigned to тоже ставят только чтобы не обидеть?
Забавно, а технический словарь говорит bug = ошибка, неисправность. Боюсь, только с вашей подачи смысл не изменится.
в таких трекерах каждая запись фактически не bug, а issue - обращение клиента.
Интересно, а assigned to тоже ставят только чтобы не обидеть?
кому то же надо поручить классификацию обращения, вот и ставят.
На практике много чего может создать проблемы, но это Не значит, что обязательно создаст.
И наоборот - на практике много что может принести пользу. В т.ч. и mysql cache.
Решение очень простое: практика; измерения и модификация настроек в соответствии с ними. Никаких "best practices" в виде "отключить кеш нафиг" или "сделать его 64Mb". Неужели все это столь сложно, madoff?
Нет не сложно, обычно всё остаётся как есть,сухо: просто иногда так, иногда сяк, ведь программисты люди суровые, и не всегда хотят оптимизировать запросы и т.п., вот и приходится нам админам изощряться и делать "сверхъестественные настройки"
Решение очень простое: практика; измерения и модификация настроек в соответствии с ними. Никаких "best practices" в виде "отключить кеш нафиг" или "сделать его 64Mb". Неужели все это столь сложно, madoff?
давайте сойдемся на том, что ваш интуитивный опыт прошлых лет
Тем не менее, наблюдаю ситуации, когда кеш более чем полезен (размер может быть и поболее указанного выше). И на самописном добре, и на массовых движках.
сейчас с распространением многопроцессорных конфигураций нуждается в пересмотре.
если раньше отключать кеш в голову никому не приходило, то сейчас хотя бы нужно попробовать.