ну короче, это уже беда прогромистов

динамика - это то что меняется на каждый запрос. То что индексирует бот - не должно изменяться на каждый запрос. Кешировать "динамику" нжинкс научился еще в 200х кажется. Если что. Т.е. прокешировать индекс пейдж сайта (сформированную динамически пхп) можно от пхпплагинов(которые генерят штмл) до нжинкс,варниш и т.д. заканчивая клаудфларе.

это так себе дисскусия без предмета

но я тоже думаю что в консерватории чет не то

динамика - это то что меняется на каждый запрос. То что индексирует бот - не должно изменяться на каждый запрос. Кешировать "динамику" нжинкс научился еще в 200х кажется. Если что. Т.е. прокешировать индекс пейдж сайта (сформированную динамически пхп) можно от пхпплагинов(которые генерят штмл) до нжинкс,варниш и т.д. заканчивая клаудфларе.

html от пыхы в кеше есть

я же сказал

это так себе дисскусия без предмета

абсолютно. точных цифр не было, зато "код гавно, программисты унылые, даешь аутоскалинг". Нет конкретики. Это как мне недавно ответили (но я не готов пока эту конкретику сформировать и озвучить)

абсолютно. точных цифр не было, зато "код гавно, программисты унылые, даешь аутоскалинг". Нет конкретики. Это как мне недавно ответили (но я не готов пока эту конкретику сформировать и озвучить)

у меня тут такая же хрень была недавно, разрабы на SAS нагородили херни, и сервера с базами еле справлялись, ответом было дать им больше ресурсов. Пока не дошло до абсурда, пришел CTO, и уволил нахер тех разрабов. Новые начали с оптимизации запросов, и урезали нагрузку на кластер SQL в 500 раз с первой попытки. Мораль сей басни наверное всем ясна

народ, а в проксе нету клауд инита родными средствами?

фа

всем привет. Может кто подскажет с чем может быть связано дикое проседание системных вызовов под KVM после установки патча KPTI? ось Centos7 host и guest. Разница (с патчем и без) на хостовой системе почти незаметна

А сам квм обновляли?

В нем же тоже был патч

от спектра

да он в центосе старый, не прилетало обновление

В проксе накатился ж, а в центос хз

реально сильно тупит прокс после установки обновления? патч от спектра ведь с обычным apt upgrade устанавливается?

я обновился до патча - пока подожду - гостей левых не хостю

я у всяких провайдеров понабрал тестовых VDS KVM и просадка от патча на моем синтетическом тесте syscall'ов в среднем в 4 раза. У меня же 28 раз

проц у меня 4 штуки Xeon L5420 2.5 Ggz.

я думаю патчи клепали впопыхах кривыми х*я**и - через месяцок норм патчи будут.

я на это очень надеюсь

пока единственный вариант у меня это отказ от виртуализации

но хостовой системе разница очень мала, а на kvm полная жопа

вот думаю, может кто уже столкнулся и как-то решил эту проблему? :)))

запостил в багтрекер redhat. Посмотрю что они ответят

у меня сраная проприетарная прога делает этот close() в общей сложности 600 тыс. раз. И это замедляет работу этой самой проги примерно в 60 раз

а без патча летает

ну вот я тоже никого чужого не хощу, но получается что уязвимые вебсервисы на одной тачке которая смотрит в интернет ставит крест на безопасности всех вм на хосте)

похоже, что на более современных процессорах патч не так заметен как на древних :(

ради этого менять сервер у которых 4 четырехядерных Xeon как-то совсем уж западло

в моем случае патч не хостовой системе не влияет на производительность системных вызовов виртуалки

а вот патч гостевой системы просаживает системных вызовы очень сильно

*патч не хостовой системе

блин

*патч на хостовой системе

вы чем то меряли перфоманс до и после? или ориентируетесь только по специфической проге?

я написал на си : test-syscall.c: void main(int argc, char *argv[]) { int i; for (i=0; i<100000; i++) { close(i); } } gcc -o test-syscall test-syscall.c

измеряю так time ./test-syscall

на вид это синтетический тест, но некторые программы делают подобное перед fork() или перед execve(), беря значение колиества файловых дескрипторов из getrlimit(RLIMIT_NOFILE, ...). В моём случае лимит на файлы 100000

у меня специфическая проприетарная прога делает подобное три раза подряд. На KVM на это уходит 0.7 с на моём проце

если в гостевой системе ядру передать nopti (отключить патч), то мой тест проходит в 28 раз быстрее , за 0.026s

у меня есть ещё один сервер Xeon на 1.8 Ггц. На нем, на KVM тест проходит за 1.1s )

если в гостевой системе ядру передать nopti (отключить патч), то мой тест проходит в 28 раз быстрее , за 0.026s

так в чем проблема-то, ты ж хост-машину пропатчил, зачем тебе на виртуалке патч иметь?

на виртуалке есть пользователи, которых могут ломануть

ну и что?

из виртуалки им всё равно не выбраться

да, но если один ломанёт другого, то будет плохо

оно там под хостинг

жалко в общем, придётся что-то мудрить или перезжать на физический сервер

я взял для теста триальные VDS KVM у трёх разных провайдеров, частоты процессора такие же как у меня 2.5 Ггц, и там такой задержки нет. На всех протестированных виртуалках время выполнения такое же как на моей хостовой системе. Везде Centos 7 с этим злополучным патачем kpti

единственное отличие - пройессоры там новее чем у меня :)

то ли у меня какая-то хрень с настройками, толи Intel реально старые процы захотел так вывести из работы

насколько я знаю pcid центос пока не умеет

интел заявляла всё что старее skylake будет ногу лизать

@Alexey50 у нас цо7 везде. Ядро из коробки отвратительно

Не виртуализация впрочем, но при установке родного ядра с патчем падение скорости до 2.5 раз

А вот если поставить 4.9 или 4.14, то все прилично

4.9 - всего 5% падение

На 4.14 почти не заметно

но как же ЯДРО РЕДХАТА САМОЕ ЛУЧШЕЕ КОКОКОКОКО

Но у нас и ЦПУ довольно новые. Haswell/Broadwell (e5v3/4)

но как же ЯДРО РЕДХАТА САМОЕ ЛУЧШЕЕ КОКОКОКОКО

отвечает Старый Хрыч

На 4.14 плюшки в виде blk-mq перекрыти оверхед патча и пострадала у сервиса только медианная задержка, стабильно но на 2%

На 4.9 пострадало все на 4-5%

На 3.10 появились 25 перцентиль ответа вырос с 300мкс до 50мс

Медиана вдвое

И т.п.

так что на графике-то?

почему после патча стало лучше?

у нас так

схоронил

но сервис специфичный, делает много мелкоблочного i/o

на запись и чтение

но впрочем как раз должен быть один из worst case'ов для патча

так что на графике-то?

load, стало не лучше, а не стало хуже, все боялись же просадки)

я стаил на гостя 4.14 ядро с патчем, лучше не стало. На хост пока не ставил

На 4.14 плюшки в виде blk-mq перекрыти оверхед патча и пострадала у сервиса только медианная задержка, стабильно но на 2%

попробую на тестовом сервере на хост 4.14 поставить, сравню

для моего процессора совершенно никаких изменений :(((

может быть при нагрузке даст что-то, но единовременные тесты как были заоблачными так и остались :(

То ж вроде писали что эти патчи/заплатки сильно повлияют на производительность старых камней, а на современных не так сильно

пасаны в мейллист прокса уже пишут - With kernel 4.13.13-3-pve: CPU BOGOMIPS: 12069.96 REGEX/SECOND: 1098494 BUFFERED READS: 82.30 MB/sec AVERAGE SEEK TIME: 15.41 ms FSYNCS/SECOND: 44.95 - With kernel 4.13.13-4-pve: CPU BOGOMIPS: 12070.84 REGEX/SECOND: 1252864 BUFFERED READS: 28.31 MB/sec AVERAGE SEEK TIME: 46.43 ms FSYNCS/SECOND: 19.14

просто вау

добро пожаловать на 10 лет назад

я смотрю у прокса в ченджлоге "KVM fix for old CPUs"

может моя проблема там решена...

а не, это от 4 декабря апдейт

подскажите для oVirt если поставить 2 машины Self-hosted как быть со storage если допустим нету внешней NFS или внешний сторадж маст хэв?

как вариант synology NFS может подойдет?

Овирт ради двух машин без стораджа - уныловато. Энжин ест прилично ресурсов. Нфс подойдет

Посмотри на прокс