Swap

[kdv]

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

заявленное противоречит фактам.
Вот беру я FB 2. Ставлю кэш 20000 страниц.
Открываю базу размером 2.5 гиг, со страницей 16к.
При таких настройках размер кэша будет около 320 мегабайт.

Вначале сервер отъел 328 метров виртуалки, а физическую не тронул.
Выполняю Select count по здоровенной таблице.
В TaskManager явно вижу рост потребления физической памяти процессом fbserver.exe, до 333 мегабайт. После чего потребление памяти остановилось.

Классический вопрос - что я делаю не так?

Так что, если дать кэш 600 метров, и база 600 метров, то она должна вся попасть в кэш без разговоров, и после этого уже никаких дисковых чтений не будет.

[hvlad]

Так что, если дать кэш 600 метров, и база 600 метров, то она должна вся попасть в кэш без разговоров, и после этого уже никаких дисковых чтений не будет.

Да. Но это процесс не быстрый, особенно при отсутствии натуралов.

[Ivan_Pisarevsky]

стандартный sata диск должен обеспечивать трансфер в среднем 40-50 мегабайт в секунду (ноутбучные - 20-30).

Дмитрий, причем тут пиковое чтение потоком и рэндамный доступ характерный для БД? САТА диск это около сотни иопсов (операций ввода вывода в секунду) при размере страницы с 16 килобайт это в худшем случае 2 мегабайта в секунду, если подфартило и несколько страниц считываются в один присест то слегонца побольше, но никак не 50 мег в секунду. Блин, ну откуда берете эти астрономические цыфры производительности?

[kdv]

Дмитрий, причем тут пиковое чтение потоком

при том, что это стандартый тест быстродействия диска. Примерно как позволяет определить вычислительную мощность процессора, и сравнить ее с другими процессорами.

Если есть два диска, и один дает в среднем 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, если сравнивать разные диски. Что подтверждается тестами.

[xvv]

Всем большое спасибо, особенно hvlad за ответ про необходимость разогрева базы. Сегодня ночью рестартую базу и проведу эксперимент с её разогревом натуральными запросами.

По результатам отчитаюсь.

Промежуточный результат мониторинга запросов приложения - нет ни одного запроса который выполняется дольше 2х секунд. Половина этого времени Prepare time (700-900ms).
На демо базе 0 секунд. В чём прикол?

[Ivan_Pisarevsky]

Если есть два диска, и один дает в среднем 30мб-сек, а другой 60 мб-сек, то это значит, что первый диск тормознее второго в два раза, вообще, т.е. на всех остальных операциях.

В общем случае это неправда. Берем новенький САТА и видавший виды скази диск, первый на потоке дает искомые 60 второй искомые 30. Ставим на каждый по БД и гоняем в многопользовательском режиме с нормальным индексным обращением к данным (мы ж не извращенцы сплошняком натуралом шпарить ). К бабке гадалке пойдем или на слово поверишь, что сказевый диск тормозить начнет под гораздо большей нагрузкой, до которой САТАшный при всей своей "мощще" даже не приблизится?

Конечно если юзер один и запросы дуром читают всю базу, то выигрыша от скази(ныне САС) вестимо не будет, но если несколько десятков юзеров долбятся ОДНОВРЕМЕННО и каждому нужно понемногу с разных учасков БД, то САТА сольет по всем статьям.

Я не спорю что неиндексные коунты и бэкап ресторы монопольно будут идти весело на САТАшных дисках, но это НЕХАРАКТЕРНЫЙ режим работы для SQL сервера, для нормально спроектированной БД более характерны таки индексные чтения от кучи одновременно долбящихся юзеров. Разница в нагрузке на диск я думаю понятна.

Из хороших потоковых характеристик не обязательно следуют хорошие рэндомные.

[xvv]

С недовольством пользователей стало понятно.
На полу-пустой базе - 40-200мс с фетчем данных.
На базе в 0,5Тб 2000-3000мс. Загоняем всё в кеш - скорость подрастает (на процентов 10-20).

Про своп понятней не стало. Упорно пишет про виртуальную память в 770м. и 107м оперативной. Я в шоке.

[hvlad]

С недовольством пользователей стало понятно.
На полу-пустой базе - 40-200мс с фетчем данных.
На базе в 0,5Тб 2000-3000мс. Загоняем всё в кеш - скорость подрастает (на процентов 10-20).

Про своп понятней не стало. Упорно пишет про виртуальную память в 770м. и 107м оперативной. Я в шоке.

500 GB ? Или всё-таки MB ?
Сколько памяти всего ?
Какой р-р страницы ?
Какой р-р кеша БД ?
Пример запроса с планом и статистикой выполнения ?

[xvv]

>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

[hvlad]

Prepare явно зашкаливает. Сам запрос выполняется нормально. Нужно включить в ИБЕ показ сист. таблиц в статистике и посмотреть сколько там откуда читается.

Но вообще-то я просил показать реальный, а не простейший, запрос. На который юзеры жалуются.

[kdv]

К бабке гадалке пойдем или на слово поверишь, что сказевый диск тормозить начнет под гораздо большей нагрузкой, до которой САТАшный при всей своей "мощще" даже не приблизится?

а ты сходи. И выдай тестовые результаты.
SATA по производительности уже давно SCSI догнали. И как бы не перегнали. Особенно если попробовать купить SATA за те же деньги что и SCSI.
Иван, ты действительно думаешь что нам не попадались тормозилища на SCSI? Неоднократно. Лучше бы эти админы запросили купить банальные стобаксовые SATA.

[kdv]

На базе в 0,5Гб 2000-3000мс. Загоняем всё в кеш - скорость подрастает

гражданин. Вы скорее всего фигню несете. Или у вас приложения написаны из рук вон плохо.

[xvv]

Они на общую скорость жалуются. Ни на что конкретного не жалуются.
Вот например один из спорных запросов:
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 (для поиска конкретного экземпляра), а индексы по остальным полям грохнул.

[xvv]

Эти два пункта мне понятны
Execute time = 688ms
Avg fetch time = 49,14 ms
А вот это нет
Prepare time = 703ms

Вопрос про скорость дисков снят этим:
Reads from disk to cache = 0

[hvlad]

В запросе в условие могут кучу разной фильтрации воткнуть. например как здесь - по sitogo (вычисляемому полю).
Так что я оставил только PK по ID (для поиска конкретного экземпляра), а индексы по остальным полям грохнул.

Запрос выглядит достаточно кривым, подзапрос в SELECT там совершенно не нужен. Индекс на KLIENT.GR возможно оказался бы не лишним.

Насчёт времени prepare я уже говорил куда смотреть

[kdv]

еще настоятельно рекомендую - форматировать запросы и использовать тег code в сообщениях. Иначе я такие портянки буду удалять.

[Ivan_Pisarevsky]

а ты сходи. И выдай тестовые результаты.
SATA по производительности уже давно SCSI догнали. И как бы не перегнали. Особенно если попробовать купить SATA за те же деньги что и SCSI.
Иван, ты действительно думаешь что нам не попадались тормозилища на SCSI? Неоднократно. Лучше бы эти админы запросили купить банальные стобаксовые SATA.

Я тут как раз по причине старости одного из своих серверов собираюсь поменять железку, вот на какое-то время будет мощный тестовый стенд, погоняю тесты. Планируются как раз САС диски, я еще последовательный скази не пробовал, заценю.

Учитывая опубликованый выше автором запрос ему надо не железо накачивать, а код до ума доводить, иначе и скази будет тормозить немилосердно.

[kdv]

кстати. буквально позавчера. пускаю свой disktest на scsi. по чтению нормально, а по записи вообще капец. тест остановил через 1.5 часа. Подумал. Полез в настройки - понятно, не включен write cache. Но. Это ж организовано так, что хер знает, у какого из трех одинаковых дисков я его включаю. Есть C, D и E. А там где кэш включается - просто висят названия моделей дисков, и все.
Но это так, побурчать.
Включил кэш, запись понеслась как чтение

[Ivan_Pisarevsky]

OFF

Дмитрий, я тут тебе запрос на sales@ibase отписал хочу дельфи прикупить c адреса pisarevsky[at]fab-rus.ru проверь чтоб в спаме не утопло, пожалуйста.