Swap
Модераторы: kdv, Alexey Kovyazin
он же говорит, что
а) скорость упала
б) дисковых чтений меньше не стало
в) физической памяти FB так и не откушал, а съел только виртуал
заявленное противоречит фактам.
Вот беру я FB 2. Ставлю кэш 20000 страниц.
Открываю базу размером 2.5 гиг, со страницей 16к.
При таких настройках размер кэша будет около 320 мегабайт.
Вначале сервер отъел 328 метров виртуалки, а физическую не тронул.
Выполняю Select count по здоровенной таблице.
В TaskManager явно вижу рост потребления физической памяти процессом fbserver.exe, до 333 мегабайт. После чего потребление памяти остановилось.
Классический вопрос - что я делаю не так?
Так что, если дать кэш 600 метров, и база 600 метров, то она должна вся попасть в кэш без разговоров, и после этого уже никаких дисковых чтений не будет.
а) скорость упала
б) дисковых чтений меньше не стало
в) физической памяти FB так и не откушал, а съел только виртуал
заявленное противоречит фактам.
Вот беру я FB 2. Ставлю кэш 20000 страниц.
Открываю базу размером 2.5 гиг, со страницей 16к.
При таких настройках размер кэша будет около 320 мегабайт.
Вначале сервер отъел 328 метров виртуалки, а физическую не тронул.
Выполняю Select count по здоровенной таблице.
В TaskManager явно вижу рост потребления физической памяти процессом fbserver.exe, до 333 мегабайт. После чего потребление памяти остановилось.
Классический вопрос - что я делаю не так?
Так что, если дать кэш 600 метров, и база 600 метров, то она должна вся попасть в кэш без разговоров, и после этого уже никаких дисковых чтений не будет.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Дмитрий, причем тут пиковое чтение потоком и рэндамный доступ характерный для БД? САТА диск это около сотни иопсов (операций ввода вывода в секунду) при размере страницы с 16 килобайт это в худшем случае 2 мегабайта в секунду, если подфартило и несколько страниц считываются в один присест то слегонца побольше, но никак не 50 мег в секунду. Блин, ну откуда берете эти астрономические цыфры производительности?kdv писал(а):стандартный sata диск должен обеспечивать трансфер в среднем 40-50 мегабайт в секунду (ноутбучные - 20-30).
при том, что это стандартый тест быстродействия диска. Примерно как позволяет определить вычислительную мощность процессора, и сравнить ее с другими процессорами.Дмитрий, причем тут пиковое чтение потоком
Если есть два диска, и один дает в среднем 30мб-сек, а другой 60 мб-сек, то это значит, что первый диск тормознее второго в два раза, вообще, т.е. на всех остальных операциях. Или, если оба диска одинаковые, но стоят на разных машинах (тоже одинаковых), то это значит что для первого диска или кривые драйверы стоят, или UltraDMA работает не на полную (кривой кабель), и т.д.
Причем, для select count, при монопольном вызове по большой таблице, PerfMon и покажет примерно такой Transfer Rate.
http://www.ibase.ru/devinfo/backupspeed.htm
"Например, для оценки производительности на всех серверах к базе был выполнен запрос select count(*) по самой большой таблице в БД. Все серверы показали один и тот же результат - 42 секунды, 50% загрузки процессора во время выполнения запроса, и disk transfer rate ~45 мегабайт в секунду (что и является максимумом по вводу-выводу для данного участка диска, где располагалась БД)."
Теперь понятно?
p.s. кстати - рандомное чтение и запись примерно пропорционально соответствуют transfer rate, если сравнивать разные диски. Что подтверждается тестами.
Всем большое спасибо, особенно hvlad за ответ про необходимость разогрева базы. Сегодня ночью рестартую базу и проведу эксперимент с её разогревом натуральными запросами.
По результатам отчитаюсь.
Промежуточный результат мониторинга запросов приложения - нет ни одного запроса который выполняется дольше 2х секунд. Половина этого времени Prepare time (700-900ms).
На демо базе 0 секунд. В чём прикол?
По результатам отчитаюсь.
Промежуточный результат мониторинга запросов приложения - нет ни одного запроса который выполняется дольше 2х секунд. Половина этого времени Prepare time (700-900ms).
На демо базе 0 секунд. В чём прикол?
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
В общем случае это неправда. Берем новенький САТА и видавший виды скази диск, первый на потоке дает искомые 60 второй искомые 30. Ставим на каждый по БД и гоняем в многопользовательском режиме с нормальным индексным обращением к данным (мы ж не извращенцы сплошняком натуралом шпарить ). К бабке гадалке пойдем или на слово поверишь, что сказевый диск тормозить начнет под гораздо большей нагрузкой, до которой САТАшный при всей своей "мощще" даже не приблизится?kdv писал(а):Если есть два диска, и один дает в среднем 30мб-сек, а другой 60 мб-сек, то это значит, что первый диск тормознее второго в два раза, вообще, т.е. на всех остальных операциях.
Конечно если юзер один и запросы дуром читают всю базу, то выигрыша от скази(ныне САС) вестимо не будет, но если несколько десятков юзеров долбятся ОДНОВРЕМЕННО и каждому нужно понемногу с разных учасков БД, то САТА сольет по всем статьям.
Я не спорю что неиндексные коунты и бэкап ресторы монопольно будут идти весело на САТАшных дисках, но это НЕХАРАКТЕРНЫЙ режим работы для SQL сервера, для нормально спроектированной БД более характерны таки индексные чтения от кучи одновременно долбящихся юзеров. Разница в нагрузке на диск я думаю понятна.
Из хороших потоковых характеристик не обязательно следуют хорошие рэндомные.
500 GB ? Или всё-таки MB ?xvv писал(а):С недовольством пользователей стало понятно.
На полу-пустой базе - 40-200мс с фетчем данных.
На базе в 0,5Тб 2000-3000мс. Загоняем всё в кеш - скорость подрастает (на процентов 10-20).
Про своп понятней не стало. Упорно пишет про виртуальную память в 770м. и 107м оперативной. Я в шоке.
Сколько памяти всего ?
Какой р-р страницы ?
Какой р-р кеша БД ?
Пример запроса с планом и статистикой выполнения ?
>500 GB ? Или всё-таки MB ?
мб. Тяжело переключаться
>Сколько памяти всего ?
2Гб
>Какой р-р страницы ?
8К
>Какой р-р кеша БД ?
10000 блоков, увеличивал до 80000
>Пример запроса с планом и статистикой выполнения ?
начиная с простейших:
select count(*) from clients
План
PLAN (KLIENT NATURAL)
Адаптированный план
PLAN (KLIENT NATURAL)
------ Performance info ------
Prepare time = 687ms
Execute time = 172ms
Avg fetch time = 172,00 ms
Current memory = 18 272 148
Max memory = 18 296 276
Memory buffers = 80 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 110 816
табличка 64К записей
тотже запрос на демо базе с 10 записями:
План
PLAN (KLIENT NATURAL)
Адаптированный план
PLAN (KLIENT NATURAL)
------ Performance info ------
Prepare time = 15ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 1 321 148
Max memory = 1 453 540
Memory buffers = 90
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 17
мб. Тяжело переключаться
>Сколько памяти всего ?
2Гб
>Какой р-р страницы ?
8К
>Какой р-р кеша БД ?
10000 блоков, увеличивал до 80000
>Пример запроса с планом и статистикой выполнения ?
начиная с простейших:
select count(*) from clients
План
PLAN (KLIENT NATURAL)
Адаптированный план
PLAN (KLIENT NATURAL)
------ Performance info ------
Prepare time = 687ms
Execute time = 172ms
Avg fetch time = 172,00 ms
Current memory = 18 272 148
Max memory = 18 296 276
Memory buffers = 80 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 110 816
табличка 64К записей
тотже запрос на демо базе с 10 записями:
План
PLAN (KLIENT NATURAL)
Адаптированный план
PLAN (KLIENT NATURAL)
------ Performance info ------
Prepare time = 15ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 1 321 148
Max memory = 1 453 540
Memory buffers = 90
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 17
а ты сходи. И выдай тестовые результаты.К бабке гадалке пойдем или на слово поверишь, что сказевый диск тормозить начнет под гораздо большей нагрузкой, до которой САТАшный при всей своей "мощще" даже не приблизится?
SATA по производительности уже давно SCSI догнали. И как бы не перегнали. Особенно если попробовать купить SATA за те же деньги что и SCSI.
Иван, ты действительно думаешь что нам не попадались тормозилища на SCSI? Неоднократно. Лучше бы эти админы запросили купить банальные стобаксовые SATA.
Они на общую скорость жалуются. Ни на что конкретного не жалуются.
Вот например один из спорных запросов:
SELECT
ID,
NAME,
CMNT,
case WHEN (NAME is null) then '*' else NAME end||case WHEN (CMNT is null) then '' else ' '||CMNT end NNN,
SOTR,
FU,
SRT,
TEL,
EMAIL,
P,
BDAY,
INN,
ADR,
DREG,
USR,
USR_TM,
M,
case when (m is null) then ' ' else 'X' end MX,
SOPL,
SZak,
Sitogo,
GR,
FOTO,
TEL2,
namefull,
kpp,
ADRPost,
ADRMain,
bik,
acck,
accr,
bank_name,
fax
FROM
KLIENT, (
SELECT MODULES.id_p
FROM USR_MODULES, MODULES
where MODULES.T=5
and USR_MODULES.MODULES=MODULES.id
and USR_MODULES.VIS='T'
and USR_MODULES.usr_usr=:USR
) x
Where gr=x.id_p
AND sitogo<>0
order by KLIENT.NAME
План
PLAN SORT (MERGE (SORT (JOIN (X MODULES INDEX (FK_MODULES), X USR_MODULES INDEX (PK_USR_MODULES))), SORT (KLIENT NATURAL)))
Адаптированный план
PLAN SORT (MERGE (SORT (JOIN (X MODULES INDEX (FK_MODULES), X USR_MODULES INDEX (PK_USR_MODULES))), SORT (KLIENT NATURAL)))
------ Performance info ------
Prepare time = 703ms
Execute time = 688ms
Avg fetch time = 49,14 ms
Current memory = 18 549 024
Max memory = 20 098 616
Memory buffers = 80 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 110 914
В запросе в условие могут кучу разной фильтрации воткнуть. например как здесь - по sitogo (вычисляемому полю).
Так что я оставил только PK по ID (для поиска конкретного экземпляра), а индексы по остальным полям грохнул.
Вот например один из спорных запросов:
SELECT
ID,
NAME,
CMNT,
case WHEN (NAME is null) then '*' else NAME end||case WHEN (CMNT is null) then '' else ' '||CMNT end NNN,
SOTR,
FU,
SRT,
TEL,
EMAIL,
P,
BDAY,
INN,
ADR,
DREG,
USR,
USR_TM,
M,
case when (m is null) then ' ' else 'X' end MX,
SOPL,
SZak,
Sitogo,
GR,
FOTO,
TEL2,
namefull,
kpp,
ADRPost,
ADRMain,
bik,
acck,
accr,
bank_name,
fax
FROM
KLIENT, (
SELECT MODULES.id_p
FROM USR_MODULES, MODULES
where MODULES.T=5
and USR_MODULES.MODULES=MODULES.id
and USR_MODULES.VIS='T'
and USR_MODULES.usr_usr=:USR
) x
Where gr=x.id_p
AND sitogo<>0
order by KLIENT.NAME
План
PLAN SORT (MERGE (SORT (JOIN (X MODULES INDEX (FK_MODULES), X USR_MODULES INDEX (PK_USR_MODULES))), SORT (KLIENT NATURAL)))
Адаптированный план
PLAN SORT (MERGE (SORT (JOIN (X MODULES INDEX (FK_MODULES), X USR_MODULES INDEX (PK_USR_MODULES))), SORT (KLIENT NATURAL)))
------ Performance info ------
Prepare time = 703ms
Execute time = 688ms
Avg fetch time = 49,14 ms
Current memory = 18 549 024
Max memory = 20 098 616
Memory buffers = 80 000
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 110 914
В запросе в условие могут кучу разной фильтрации воткнуть. например как здесь - по sitogo (вычисляемому полю).
Так что я оставил только PK по ID (для поиска конкретного экземпляра), а индексы по остальным полям грохнул.
Запрос выглядит достаточно кривым, подзапрос в SELECT там совершенно не нужен. Индекс на KLIENT.GR возможно оказался бы не лишним.xvv писал(а):В запросе в условие могут кучу разной фильтрации воткнуть. например как здесь - по sitogo (вычисляемому полю).
Так что я оставил только PK по ID (для поиска конкретного экземпляра), а индексы по остальным полям грохнул.
Насчёт времени prepare я уже говорил куда смотреть
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Я тут как раз по причине старости одного из своих серверов собираюсь поменять железку, вот на какое-то время будет мощный тестовый стенд, погоняю тесты. Планируются как раз САС диски, я еще последовательный скази не пробовал, заценю.kdv писал(а): а ты сходи. И выдай тестовые результаты.
SATA по производительности уже давно SCSI догнали. И как бы не перегнали. Особенно если попробовать купить SATA за те же деньги что и SCSI.
Иван, ты действительно думаешь что нам не попадались тормозилища на SCSI? Неоднократно. Лучше бы эти админы запросили купить банальные стобаксовые SATA.
Учитывая опубликованый выше автором запрос ему надо не железо накачивать, а код до ума доводить, иначе и скази будет тормозить немилосердно.
кстати. буквально позавчера. пускаю свой disktest на scsi. по чтению нормально, а по записи вообще капец. тест остановил через 1.5 часа. Подумал. Полез в настройки - понятно, не включен write cache. Но. Это ж организовано так, что хер знает, у какого из трех одинаковых дисков я его включаю. Есть C, D и E. А там где кэш включается - просто висят названия моделей дисков, и все.
Но это так, побурчать.
Включил кэш, запись понеслась как чтение
Но это так, побурчать.
Включил кэш, запись понеслась как чтение
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34