Исходное сообщение
"Значительное снижение производительности MyISAM при включени..." Отправлено IZh., 14-Фев-18 12:10
If we look at the handler status variables, we can see that for 8K rows the query does more than 50 million calls to Handler_read_rnd_next. For MyISAM such a handler call results in a call to fget() which in turn results in a __fget syscall. This is so, because the MyISAM engine does not have a row cache. While it caches index pages in the Key Buffer, there is no such cache for row data. For that it relies on the generic page cache in the operation system. That works pretty well, however since that cache is in the kernel, there is the syscall barrier between the MariaDB server and the cache. The page table isolation introduced with KPTI increases the cost for a syscall. Hence a workload like the one above, where many MyISAM rows are read in a tight loop, becomes notably slower. The relative slowdown is actually bigger when the row is already in the page cache!

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> If we look at the handler status variables, we can see that > for 8K rows the query does more than 50 million calls > to Handler_read_rnd_next. For MyISAM such a handler call results in a > call to fget() which in turn results in a __fget syscall. > This is so, because the MyISAM engine does not have a row > cache. While it caches index pages in the Key Buffer, there > is no such cache for row data. For that it relies > on the generic page cache in the operation system. That works > pretty well, however since that cache is in the kernel, there > is the syscall barrier between the MariaDB server and the cache. > The page table isolation introduced with KPTI increases the cost for a > syscall. Hence a workload like the one above, where many MyISAM > rows are read in a tight loop, becomes notably slower. The > relative slowdown is actually bigger when the row is already in > the page cache!
	Введите код, изображенный на картинке: