Параллельное выполнение запросов

pticelov · Сообщение **pticelov** » 07 июн 2006, 00:23

ФАК читал. Знаю, что IB умеет выполнять параллельно запросы, если они порождены с разных коннектов, с обязательным условием - коннект по сети, а не локальный. localhost: годится.

А что у огненной птицы? Проверял. Если сервер у меня уходит в себя на сложном запросе, приконнектиться к БД неудается никак. FB 1.5.3

eugeney · Сообщение **eugeney** » 07 июн 2006, 09:06

pticelov писал(а):ФАК читал. А что у огненной птицы? Проверял. Если сервер у меня уходит в себя на сложном запросе, приконнектиться к БД неудается никак. FB 1.5.3

Читай про различия CS и SS

dimitr · Сообщение **dimitr** » 07 июн 2006, 09:06

на 2.0 SS этой проблемы тоже не должно быть

Сообщение **kdv** » 07 июн 2006, 09:32

А что у огненной птицы? Проверял.

при чем тут это. FB базируется на коде IB 6. Или ты сравниваешь с IB 7.5? тогда тебе ответили про Classic.
Собственно, разумеется, SuperServer тоже выполняет запросы "параллельно", иначе бы что это был за многопользовательский сервер.
Другое дело, что в обычном SS тяжелый запрос приводит к замедлению выполнения остальных.

pticelov · Сообщение **pticelov** » 08 июн 2006, 02:02

kdv писал(а):
А что у огненной птицы? Проверял.
при чем тут это. FB базируется на коде IB 6. Или ты сравниваешь с IB 7.5?

Я не сравниваю с 7.5. Я фак читаю

"Начиная с IB 4.2 клиентская часть IB поддерживает параллельное выполнение операций в разных коннектах"

kdv писал(а):тогда тебе ответили про Classic.
Собственно, разумеется, SuperServer тоже выполняет запросы "параллельно", иначе бы что это был за многопользовательский сервер.
Другое дело, что в обычном SS тяжелый запрос приводит к замедлению выполнения остальных.

когда у меня файрбирд уходит "подумать на полчасика" со 100% загрузкой процессора, коннекты не проходят нафииг. SS 1.5.3

CyberMax · Сообщение **CyberMax** » 08 июн 2006, 03:51

1. Приоритет процесса сервера случайно не повышенный? Если да, то это неудивительно.
2. ОС?
3. Конфигурация сервера.

Сообщение **kdv** » 08 июн 2006, 09:24

"Начиная с IB 4.2 клиентская часть IB поддерживает параллельное выполнение операций в разных коннектах"

КЛИЕНТСКАЯ ЧАСТЬ! Клиент может открыть два коннекта в разных тредах, и выполнять запросы ПАРАЛЛЕЛЬНО. Клиент, еще раз повторяю.
Сервер же умеет параллельно запросы выполнять ПО ОПРЕДЕЛЕНИЮ.

pticelov · Сообщение **pticelov** » 08 июн 2006, 10:22

1. Насчет "клиентской части" - дошло.

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

to cybermax:
1. приоритет не повышен
2. XP, system restore отключено нафиг
3. 2.8 GHz dual P4, 3GB RAM, SATA RAID-1

100% загрузки процессора - это 100% загрузки одного из двух процессоров, конечно, таскменеджер пишет в таких случаях 50%

параллельные запросы пытался делать своей программой и flamefobin'лм, сегодня сделю тест только на свою программу

pticelov · Сообщение **pticelov** » 09 июн 2006, 02:39

Вскрытие показало, что все0таки умеет выполнять конкурирующий запрос, мне просто терпения не хватало. Если запрос X начинает жрать 100% ресурсов, то запрос Y с нормальным временем выполнения в единицы миллисекунд проходит за минуты, а коннект и ошибочный запрос - порядка минуты.

Так и должно быть? Я бы не назвал это многопользовательским режимом.

Решение, как я понимаю, 1.5 CS или 2.0 SS вместо 1.5 SS

CyberMax · Сообщение **CyberMax** » 09 июн 2006, 02:59

pticelov писал(а):Так и должно быть? Я бы не назвал это многопользовательским режимом.

Дело в чьих-то кривых руках. У других же все работает. У меня, например

. Никаких тормозов при коннекте.

pticelov писал(а):Решение, как я понимаю, 1.5 CS или 2.0 SS вместо 1.5 SS

CS - только если у тебя более одного процессора на компе. Да и толку, если у тебя на 1.5 не работает нормально.

Скинь сюда инфу по базе:
gstat -h Имябазы.fdb (gstat в \bin каталоге firebird'а)

cav · Сообщение **cav** » 09 июн 2006, 12:30

2. XP, system restore отключено нафиг
3. 2.8 GHz dual P4, 3GB RAM, SATA RAID-1

И Супер сервер.....

. Иногда надо конкретно указать на каком проце должен висеть процес FB

CyberMax · Сообщение **CyberMax** » 09 июн 2006, 13:25

cav писал(а):И Супер сервер..... . Иногда надо конкретно указать на каком проце должен висеть процес FB

Проглядел, что dual

. Согласен про CPU Affinity. Но вряд ли сильно это поможет. Ждем статистики.

pticelov · Сообщение **pticelov** » 09 июн 2006, 15:43

Докладываю

Поспомтрел статистику. Увидел большой sweep gap (прнимерно 3000) при интервале 20000. Для отчистки советси сделал sweep. Поулчил статистику такую:

Database header page information:
Flags 0
Checksum 12345
Generation 120103
Page size 16384
ODS version 10.1
Oldest transaction 120047
Oldest active 120048
Oldest snapshot 120048
Next transaction 120049
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 65535
Next header page 0
Database dialect 3
Creation date Apr 26, 2006 4:19:39
Attributes

Variable header data:
Sweep interval: 20
*END*

запустил тест, вырубив все лишнее. Тест коннектится через ODBC к localhost:БД, и делает несколько запросов, сопровождая все сообщениями:
1. некорректный запрос
2. простой запрос на выбор одного значения с поиском по индексу
3. запрос, уводящий файрбирда в 100% цикл

запустил первый экземпляр, получил мгновенную реакцию на тесты 1,2, после чего файрбирд занялся своим вечным циклом

запустил второй экземпляр. Рузультат - медленно (десяток секунд вместо долей секунды на коненкт и первые 2 теста), но похоже на признаки жизни.

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

Прибил все, прибил файрбирд, повторил (свеп гап уже не 1).

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

птоврил процедуру с перезапуском еще несколько раз - результат аналогичный.

to cybermax: "у меня все работает" - не совсем верный ответ. Я тестирую параллельную работу на тесте, в котором файрбирд уходит на десятки минут в непонятный цикл с 100% загрузкой на запросе (смотри предыдущий тред). Вряд-ли у тебя имеет место подобное - такую ситуацию никак нельзя признать нормальной.

Merlin · Сообщение **Merlin** » 09 июн 2006, 15:56

pticelov писал(а): to cybermax: "у меня все работает" - не совсем верный ответ. Я тестирую параллельную работу на тесте, в котором файрбирд уходит на десятки минут в непонятный цикл с 100% загрузкой на запросе (смотри предыдущий тред). Вряд-ли у тебя имеет место подобное - такую ситуацию никак нельзя признать нормальной.

Виш какое дело. Я тут тоже на днях настрочил запросец, запустил, и отправил в даун 4-х каменный сервак под пИнгвином так, что к нему телнетом не подцепиться было, не то что птичкой. А потом почесал репу, переписал по другому, и стал получать то, что нужно, меньше чем за секунду. Улавливаешь направление мыслей?

Dimitry Sibiryakov

Это как в рекламе: если не справляется один волк, запряги двоих. Жар-птичка бесплатна. Поставь супер на один сервер, классик на другой и грузи длинными запросами классик. А супер пусть быстренько работает с простыми.

CyberMax · Сообщение **CyberMax** » 10 июн 2006, 16:42

У тебя размер страницы 16384 байта. Размер кэша - 65535. Итого объем кэша в байта - 1 073 725 440 байт, а это целый гигабайт. Если у тебя оперативы меньше 1,5 ГГб и в случае, если запрос оперирует с большим количеством страниц, это вызовет жесточайший своп кэша сервера на винт.
Поставь кэш на 512 страниц и перезапусти этот запрос. В любом случае, 65535 - это слишком много. Не забывай, что Windows все равно кэширует все твои страницы.

pticelov · Сообщение **pticelov** » 10 июн 2006, 17:42

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

CyberMax:

"У тебя размер страницы 16384 байта. Размер кэша - 65535. Итого объем кэша в байта - 1 073 725 440 байт, а это целый гигабайт. Если у тебя оперативы меньше 1,5 ГГб и в случае, если запрос оперирует с большим количеством страниц, это вызовет жесточайший своп кэша сервера на винт"

Я перед тем:

"2.8 GHz dual P4, 3GB RAM, SATA RAID-1"

Столь очевидные вещи я понимаю, честное слово

Dimitry Sibiryakov:

"Поставь супер на один сервер, классик на другой и грузи длинными запросами классик. А супер пусть быстренько работает с простыми"

Merlin туда же.

Я перед тем:

"Я тестирую параллельную работу на тесте, в котором файрбирд уходит на десятки минут в непонятный цикл с 100% загрузкой на запросе (смотри предыдущий тред)."

Я не смогу перенести "тормозные" запросы на другой сервер - заранее я не знаю, какой из них тормозит. Сервенр уходит в даун при определенных значениях параметров (что мы в другом треде и обсуждаем). В данном треде меня не интересует, как улучшить запрос (это, само собой, должно быть сделано), а нейтрализация глюка, если он вдруг все же проявится. Хорошим решением с моей точки зрения является распараллеливание запросов, поскольку уход одного треда в 100% цикл - не смерть компьютеру, все должно работать, пусть и в 2 раза медленее. Вот об этом я и пытаюсь получить ответ: так и должно быть, или у меня руки кривые. Если так и должно быть - то мне судьба пересаживаться на classic 1.5 или super 2.0, если руки кривые - так надо выпрямить

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

CyberMax · Сообщение **CyberMax** » 10 июн 2006, 18:02

Про размер оперативки - мой косяк. Но ты все равно уменьши размер кэша базы. Это первое. Второе - размер базы? Если небольшой, то можно залить ее куда-нибудь (само собой, перед этим заменив реальные данные на случайные). Посмотрим, базу это виновата или сервак.

pticelov · Сообщение **pticelov** » 10 июн 2006, 19:12

База - 9Г.

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

Но зачем мне снижать производительность?

CyberMax · Сообщение **CyberMax** » 11 июн 2006, 15:03

Производительность под Windows никак не уменьшится, скорее наоборот. Она автоматически откеширует страницы (посмотри размер системного кэша в диспетчере задач. В твоем случае он должен быть порядка 2,5 Гб). А тут у тебя получается двойное кэширование - сначала в firebird'е, потом в ОС.
Скинь лучше запрос, на котором у тебя сервак уходит в партизаны.