Загрузка винчестера при работе FB 1.5.3
Модераторы: kdv, Alexey Kovyazin
Загрузка винчестера при работе FB 1.5.3
Здравствуйте All,
//Железо
Pentium4 3.06
HT отключен
1 Gb RAM
SCSI RAID 5 (Promise 14100)
//Софт
ALTlinux
FB 1.5.3 SS
// проблема
Проблема в небольшой производительности и медленной выдаче ответов при большой (относительно) загрузке...
Запросы к базе осуществляются с периодом в 20с, одновременное число клиентов 30, есть возможность практически одновременного доступа к базе. Данный доступ на чтение, при чем одинаковой информации. Сама база не большая (записи исчисляются тысячами).
При возникновении трудностей :
1) загрузка сети незначительна
2) ресурсы компьютера используются в половину (как проц так и оперативка)
3) замечено, что проблемным местом является дисковый массив... вернее его загруженность при работе FB
перенос на другой массив ситуацию не поменяло
// дополнительно
DefaultDbCachePages = 16К
// gstat
Flags 0
Checksum 12345
Generation 67594646
Page size 16384
ODS version 10.1
Oldest transaction 67497632
Oldest active 67497633
Oldest snapshot 67497498
Next transaction 67594635
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Sweep interval: 20000
я прошу посоветовать что можно сделать для улучшения ситуации, просьба советы выражать не учитывая "кривые руки" либо "кривые запросы", пока хочется услышать возможные дополнительные настройки... спасибо
PS: есть ли IBAnalyst под линукс ?, как я понял он только для форточек...
//Железо
Pentium4 3.06
HT отключен
1 Gb RAM
SCSI RAID 5 (Promise 14100)
//Софт
ALTlinux
FB 1.5.3 SS
// проблема
Проблема в небольшой производительности и медленной выдаче ответов при большой (относительно) загрузке...
Запросы к базе осуществляются с периодом в 20с, одновременное число клиентов 30, есть возможность практически одновременного доступа к базе. Данный доступ на чтение, при чем одинаковой информации. Сама база не большая (записи исчисляются тысячами).
При возникновении трудностей :
1) загрузка сети незначительна
2) ресурсы компьютера используются в половину (как проц так и оперативка)
3) замечено, что проблемным местом является дисковый массив... вернее его загруженность при работе FB
перенос на другой массив ситуацию не поменяло
// дополнительно
DefaultDbCachePages = 16К
// gstat
Flags 0
Checksum 12345
Generation 67594646
Page size 16384
ODS version 10.1
Oldest transaction 67497632
Oldest active 67497633
Oldest snapshot 67497498
Next transaction 67594635
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Sweep interval: 20000
я прошу посоветовать что можно сделать для улучшения ситуации, просьба советы выражать не учитывая "кривые руки" либо "кривые запросы", пока хочется услышать возможные дополнительные настройки... спасибо
PS: есть ли IBAnalyst под линукс ?, как я понял он только для форточек...
Это тебе ни о чём не говорит?Oldest transaction 67497632
Oldest active 67497633
Oldest snapshot 67497498
Next transaction 67594635
почитай про сборку мусора здесь же (на этом сайте)
а что тебе мешает его использовать с клиента на Виндах?есть ли IBAnalyst под линукс ?, как я понял он только для форточек..
там help очень хороший
если кратко, то здесь
http://www.ibase.ru/devinfo/summary.htm
К сожалению, не указан точный размер базы.
1. У тебя сейчас разница между старейшей активной транзакцией и следующей транзакцией почти 100 000... То есть существуют "висящие" транзакции, которые держат версии записей. Есть повод задуматься над клиентской частью.
2. У тебя "намотано" уже 67 миллионов транзакций. Интересно, как давно делался бэкап/рестор?..
Не забудь почитать мануалы на эту тему на http://www.ibase.ru/develop.htm.
1. У тебя сейчас разница между старейшей активной транзакцией и следующей транзакцией почти 100 000... То есть существуют "висящие" транзакции, которые держат версии записей. Есть повод задуматься над клиентской частью.
2. У тебя "намотано" уже 67 миллионов транзакций. Интересно, как давно делался бэкап/рестор?..
Не забудь почитать мануалы на эту тему на http://www.ibase.ru/develop.htm.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Спасибо за помощь, дочитываю все что не дочитал...
что касается разницы между трансакциями, то может быть такой случай... разница в 1... после чего резко 10000... и снова 1... сказывается практически одновременный досиуп клиентов
...есть вопрос по IBAnalyst, допускаю что он будет тривиальным...
я так понимаю gds32.dll генерируется вместе с устанвкой сервера... как быть в случае с линуксом ? ...достаточно ли будет скачать виндовый сервер и после установки выдрать библиотеку для работы с никсовым сервером ?
бэкап/рестор делается каждый день2. У тебя "намотано" уже 67 миллионов транзакций. Интересно, как давно делался бэкап/рестор?..
к сожалению бэкап/рестор уже сделан. но повторить ситуацию не будет сложно.возьми IBAnalyst здесь же на форуме, глянь им header page.
базу рекомендую забэкапить-заресторить. Но ! предварительно статистику, полученную в IBA, прислать на support-ibase.ru.
что касается разницы между трансакциями, то может быть такой случай... разница в 1... после чего резко 10000... и снова 1... сказывается практически одновременный досиуп клиентов
16 кбайт, выставлено в ходе экспериментов, пусть даже это много, пока будет именно так... по крайней мере уменьшение пока на производительность не влияет16K страниц кэша это как? Если 16 тысяч, то для полуторки многовато. Если просто 16, то для супера маловато.
исключеноДа и вообще промис фуфло тормозное и глючное, его лучше сменить, на адаптек или ЛСИ.
...есть вопрос по IBAnalyst, допускаю что он будет тривиальным...
я так понимаю gds32.dll генерируется вместе с устанвкой сервера... как быть в случае с линуксом ? ...достаточно ли будет скачать виндовый сервер и после установки выдрать библиотеку для работы с никсовым сервером ?
и что это за задача такая, что В ДЕНЬ 67 миллионов транзакций?бэкап/рестор делается каждый день
это ж 775 транзакций в секунду круглые сутки.
у вас все клиенты линуксовые?..есть вопрос по IBAnalyst, допускаю что он будет тривиальным...
я так понимаю gds32.dll генерируется вместе с устанвкой сервера... как быть в случае с линуксом ? ...достаточно ли будет скачать виндовый сервер и после установки выдрать библиотеку для работы с никсовым сервером ?
gds32.dll могу прислать.
тут придется пооткровенничать... я не являюсь ни разработчиком системы ни администратором базы... могу сказать только, что происходит мониторинг клиентов, на предмет активности,... т.е. фиксирование нажатий клавишь, кнопочек, изменений размеров форм... и тд. , и это не считая кучи другой нагрузки... в которую я просто не посвещен... в то же время разработчики связаны с внешним миром только посредством телефона и порой gprs... вот и приходится вам выслушивать мои "сказки"...и что это за задача такая, что В ДЕНЬ 67 миллионов транзакций?
это ж 775 транзакций в секунду круглые сутки.
да, клиенты все под линукс... значит ли это, что с аналистом придется работать посредством одной статистики ?у вас все клиенты линуксовые?
(добавлено) если вопрос звучал как, "есть ли что-то под ос виндовс?", то да, имеется.
т.е. хватит выдраного...gds32.dll могу прислать.
Последний раз редактировалось Ashlander 22 сен 2006, 12:44, всего редактировалось 1 раз.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Кэш не меряется в килобайтах. Кэш меряется в страницах. Что думает сервер по поводу буквы после числа я не берусь предсказать.Ashlander писал(а):16 кбайт, выставлено в ходе экспериментов, пусть даже это много, пока будет именно так... по крайней мере уменьшение пока на производительность не влияет16K страниц кэша это как? Если 16 тысяч, то для полуторки многовато. Если просто 16, то для супера маловато.
извеняюсь, это я проглядел... но действительно 16 тысяч страниц по 16 килобайт ....Кэш не меряется в килобайтах. Кэш меряется в страницах. Что думает сервер по поводу буквы после числа я не берусь предсказать.
16К употребилось просто потому, что не хотелось дописывать 3 цыфры , все писалось на слух