iBase.ru Forum

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

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

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

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

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

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

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

kdv писал(а):

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

при чем тут это. FB базируется на коде IB 6. Или ты сравниваешь с IB 7.5?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Докладываю

Поспомтрел статистику. Увидел большой 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% загрузкой на запросе (смотри предыдущий тред). Вряд-ли у тебя имеет место подобное - такую ситуацию никак нельзя признать нормальной.

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

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

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

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

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

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

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

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

База - 9Г.

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

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