Dimitry SibiryakovСимонов Денисда ладно. У автора SS, и если я правильно понял всё rdp коннекты и
есть коннекты к БД, а значит их количество не велико.
Вопрос не в количестве коннектов, а в качестве. В каждой из шести rdp сессий запущен
explorer и чёрт знает какие ещё программы, включая ту, что обращается к БД. Это примерно
так по гигабайту на сессию. На файловый кэш ничего не остаётся, всё что может - уходит в своп.
Аффтар даже не сказал какой именно процесс начинает жрать процессор при поиске товара.



ничего себе вы товарищи как быстры! думал раз оповещений на почте нет тут тишина!
давайте по порядку.

из программ запущенных всегда это помимо основной рабочей, the bat! на 2х из 6 клиентах
изредка включают chrome

GallemarТак,давай развернутые ответы на вопрос:
1. Код программы у тебя есть? Ты можешь сказать каким запросом реализован поиск?
2. Ядер сколько? HT есть?
3. Не запустился x64 - что не понравилось,код ошибки в студию.
4. Сделай gstat -h и данные выложи,только под спойлером
Пока хватит.


1. кода нет, программа на тех. поддержке пензенских умельцев собравщих сие чудо. но с ними я уже устал бороться, чаще всего отписывают в плане "а хер знает почему все так"
2. ядер 2, есть ht
3. при запуске подключении к базе вылетает вот это
4. не все знаю как делать с базой, но кажется получилось, то?

Gallemar
И какое подключение программа пользует сейчас ? На сервере терминалов.



C:\base\base.fdb

Gallemardusblinovс фрагментацией самой базы firebird проблем нет, частенько прогоняю через gbak gfix, все началось именно при работе на windows server.

А раньше какой сервер был?

раньше была связь между 2мя ПК репликацией базы настроена. после расширения до 6 репликация стольких клиентов нас поимела конкретно, восстанавливали работоспособность базы почти неделю, в итоге я настоял на сервере/и удаленных рабочих столах.

гадалкоDimitry SibiryakovPS: Видео не смотрел.

А зря. Там кусок диспетчера задач, 1.8Гб занято показывает. И еще моргает курсор в виде песочных часов с надписью внизу SQL. Помнится у ФИБов был какой-то глюк, связанный с тормозами при использовании TpFIBDataSet.SQLScreenCursor=crSQLWait, проявлявшийся на платформе Win7. ТС, загрузка 20-30% приходится на само приложение, а не на FB?

нагрузка идет именно на firebird
[youtube=

чтобы не вводить вас в заблуждение показываю как это работает на ПК который я из за этих тормозов не перевожу пока в RDP и подключаюсь к на нем напрямую к базе. работает так: программа сама офлайн на ПК при коннекте адрес базы введен "185.15.nn.3n:c:\base.fbd". видно на видео что ЦП при поиске не загружается, и все работает +- стабильнее. хотя конечно тоже не идеально, но, если зависание на удаленном рабочем столе всегда, то тут они не так мешают работать.

Симонов Денисdusblinov3. при запуске подключении к базе вылетает вот это


если хочешь перейти на x64, то перекомпилируй UDF под x64.

Исходники приложения есть?

откуда? программулина платная для ресторанов, обслуживается и дорабатывается за деньги причем иногда не совсем адекватные
я поэтому и пришел сюда чтобы понять в какую сторону копать потому что эти "бакланы-разработчики" не могут нормально ответить на вопрос как ускорить процесс, мол обычно пользуются локально(и база и программа) на одном ПК и проблем нет.

Если вопрос в ядрах и GH процессора то поменяем, не вопрос. если это тупит firebird то прощу совета по этому вопросу.

Симонов ДенисdusblinovPage size 4096
маловато будет. Я бы отресторил с 8192

посмотрим в firebird.conf

DefaultDbCachePages чему равен?


где можно этот page size увеличить?
DefaultDbCachePages = 2048
можно подробнее?Симонов ДенисА вообще FB от RDP надо отдельно ставить

Симонов Денис,
сделать сначало gbak получить файл с .fbk а после обратно уже с -size_page 8192 ??

Симонов Денисdusblinovсделать сначало gbak получить файл с .fbk а после обратно уже с -size_page 8192 ?
да, но сначала скопировать исходный файлик куды-нибудь, чтобы вернуться назад можно было. Причём копировать надо при отключенных пользователях.

dusblinovDefaultDbCachePages = 2048

для SS можно увеличить до 8196 или 16382
всё равно криво написанное приложение это не исправит

На сколько криво вы считаете? может есть конкретные претензии им на исправление?
про x64 и UDF это конкретный один файл или вшит куда то далеко в exe? просто выпадает такая же ошибка на x32 если один dll файл из исходной программы не закинуть в папку fidebird/udf. но если его закинуть в SS x64 папку fidebird/udf то эффект 0.

Gallemardusblinovпро x64 и UDF это конкретный один файл или вшит куда то далеко в exe? просто выпадает такая же ошибка на x32 если один dll файл из исходной программы не закинуть в папку fidebird/udf. но если его закинуть в SS x64 папку fidebird/udf то эффект 0.
UDF под разные системы отличаются. Это файлики в папке Firebird/UDF с расширением dll. Всё,остальное в личку:)

хоть убей не вижу нигде тут у вас "личные сообщения" ) напиши сам плиз?

Dimitry Sibiryakovdusblinovраньше была связь между 2мя ПК репликацией базы настроена. после
расширения до 6 репликация стольких клиентов нас поимела конкретно, восстанавливали
работоспособность базы почти неделю
А вот отсюда поподробнее, пожалуйста. Что за репликация, как была настроена и каким именно
способом она вас конкретно поимела?
dusblinovв итоге я настоял на сервере/и удаленных рабочих столах.
Ну, сам настоял, сам и наступил. Зачем ты сервер БД и терминальный на одно железо
взгромоздил, да ещё и такое хилое?..

Репликация была настроена так: одна центральная база и в нее заливались изменения с маленьких клиентских баз.
но она очень часто переставала работать на клиентских(просто переставала как должна каждые 2 минуты), и случалось фигня что заказы вместо сегодняшнего дня сваливались в таблицы вчерашнего, в итоге путалось всё, и однажды это случилось на праздниках и никто не видел что за 5 дней база набрала в себя 4 гб и не перестала отзываться на gbak или саму программу. "поимела" в смысле по нашим списаниям товара, заказам,клиентских бонусов, все за пару недель стерлось. отдавали им в техподдержку, они исправили.
на счет железа как раз был самый просто вариант сделать так для начала. что вы предлагаете?ради firedird брать отдельное железо? оно же работает, может быть просто увеличить его?

Dimitry SibiryakovdusblinovРепликация была настроена так: одна центральная база и в нее заливались
изменения с маленьких клиентских баз.
но она очень часто переставала работать на клиентских(просто переставала как должна каждые
2 минуты)
Во-первых, повторяю вопрос медленно: что за средство репликации использовалось?
Во-вторых, что за "просто переставала"? Какие сообщения были в её логе?


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

24.02.2014 20:47:02 -> Error replication: Dynamic SQL Error
SQL error code = -104
Unexpected end of command - line 54, column 618
19.03.2014 13:55:08 -> Error replication: lock conflict on no wait transaction
13.04.2014 12:23:27 -> Error replication: validation error for column ORDERID, value "*** null ***"

Dimitry SibiryakovPS: Ну а бред про "попадание в другие таблицы" оставим на совести архитекторов.

Dimitry Sibiryakov
PS: Бред спрятанный под спойлером всё равно остаётся бредом.


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