Там не указана конкретная модель ЦПУ.
16 ядерных голдов существует несколько модификаций в 3 поколениях.
НО из представленных вариантов вами, вероятнее всего gold будут +- такими же как эпик
а зеоны хуже 2295 и 2145 ? Ну и голдов как бы 2 штуки.
Эпику совсем тяжело у нас одному
https://www.hetzner.com/dedicated-rootserver/dell/dx292 вот такой
У нас не сервис очереди но сервер очередей используем в разных целях (Rabbitmq). У нас сервис по взаимопиару в социальных сетях.
Сеть не забита, сервера в 1 стойке.
запрос статичен, выборка меняется по 4000 раз в секунду из за инсертов туда
Эта переменная динамическая. просто вырвана из контекста кода. Доупстим там 84378234, а в след запрос 78432878
Сравните EXPLAIN-ы.
У меня не захотел подтягиваться индекс во второй таблице даже через FORCE INDEX c NOT EXISTS, хотя у вас как бы тянет.
Но смущает длина индекса по первой таблице
не похоже на пробелму с индексами, такая конструкция как сейчас спокойно выдерживает 2-3к одновременных селектов. Если подваливает под 4к+ начинает сильно нагружаться процессор, как будто нехватает ресурсов
А Вы данные со второй таблицы и не запрашивайте, а добавьте в WHERE условие что-то вроде:
Вижу в таск 3 индекса
а какой смысл в лефт джойн? какой выйгрыш может быть? у нас раньше он итак стоял, сменили на NOT exitst
да и они все используются
Я имел в виду, в таблице есть другие индексы, которые не используются другими запросами.
А ресурсы на их поддержание тратятся.
в таск есть еще один индекс но он используется в другом скрипте
Покажите CREATE TABLE
Может у вас неиспользуемые индексы
Здравствуйте. Индексы использует
id select_type table type possible_keys key key_len ref rows Extra1 PRIMARY task ref stat_task,getlist,getlist_bot getlist_bot 6 const,const,const,const 8731 Using index condition; Using where
id select_type table type possible_keys key key_len ref rows Extra2 DEPENDENT SUBQUERY flow index_subquery user_url_executor user_url_executor 8 func,const 1 Using index; Using where
