Cервер HSQLDB 1.8.0.10 - как избавиться от тормоза?

[Yakov]

Запустите jconsole  (идёт в составе jdk)
С его помощью можно посмотреть потребление памяти.

[serkondr]

serverdb@serverdb-nT535 ~ $ free
            total       used       free     shared    buffers     cached
Память:    7961956    3225668    4736288          0     156680    1189056
-/+ буферы/кэш:    1879932    6082024
Swap:            0          0          0

Встроенные базы грохнулись после нескольких сотен записей. Делал локальную внешнюю базу, а потом уже перешёл на клиент-сервер. Клиент с ООО под линукс-минт 11 на яве 1.6.23 имел гигантские тормоза при просмотре и прокрутке таблиц. После даунгрейда до 1.6.21 тормоза пропали. На винде такого не было.

[serkondr]

Шайтан, однако.

Код Выделить Развернуть

serverdb@serverdb-nT535 ~ $ jconsole
Приложение 'jconsole' может быть найдено в следующих пакетах:
* openjdk-7-jdk
* openjdk-6-jdk
Попробуйте: sudo apt-get install <выбранный пакет>

serverdb@serverdb-nT535 ~ $ sudo apt-get install openjdk-7-jdk
Чтение списков пакетов... Готово
Построение дерева зависимостей       
Чтение информации о состоянии... Готово
Будут установлены следующие дополнительные пакеты:
  icedtea-7-jre-jamvm openjdk-7-jre openjdk-7-jre-headless
Предлагаемые пакеты:
  openjdk-7-demo openjdk-7-source visualvm sun-java6-fonts
  fonts-ipafont-gothic fonts-ipafont-mincho ttf-telugu-fonts ttf-oriya-fonts
  ttf-kannada-fonts ttf-bengali-fonts
Рекомендуемые пакеты:
  libxt-dev libgconf2-4
НОВЫЕ пакеты, которые будут установлены:
  openjdk-7-jdk
Пакеты, которые будут обновлены:
  icedtea-7-jre-jamvm openjdk-7-jre openjdk-7-jre-headless
обновлено 3, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 168 пакетов не обновлено.
не установлено до конца или удалено 1 пакетов.
Необходимо скачать 61,3 MБ архивов.
После данной операции, объём занятого дискового пространства возрастёт на 28,3 MB.
Хотите продолжить [Д/н]? y
ВНИМАНИЕ: Следующие пакеты невозможно аутентифицировать!
  openjdk-7-jre icedtea-7-jre-jamvm openjdk-7-jre-headless openjdk-7-jdk
Установить эти пакеты без проверки [y/N]? y
Ош  http://archive.ubuntu.com/ubuntu/ saucy-updates/main openjdk-7-jre i386 7u55-2.4.7-1ubuntu1~0.13.10.1
  404  Not Found [IP: 91.189.88.149 80]
Ош  http://security.ubuntu.com/ubuntu/ saucy-security/main openjdk-7-jre i386 7u55-2.4.7-1ubuntu1~0.13.10.1
  404  Not Found [IP: 91.189.91.24 80]
Ош  http://security.ubuntu.com/ubuntu/ saucy-security/main icedtea-7-jre-jamvm i386 7u55-2.4.7-1ubuntu1~0.13.10.1
  404  Not Found [IP: 91.189.91.24 80]
Ош  http://security.ubuntu.com/ubuntu/ saucy-security/main openjdk-7-jre-headless i386 7u55-2.4.7-1ubuntu1~0.13.10.1
  404  Not Found [IP: 91.189.91.24 80]
Ош  http://security.ubuntu.com/ubuntu/ saucy-security/main openjdk-7-jdk i386 7u55-2.4.7-1ubuntu1~0.13.10.1
  404  Not Found [IP: 91.189.91.24 80]
Не удалось получить http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-7/openjdk-7-jre_7u55-2.4.7-1ubuntu1~0.13.10.1_i386.deb  404  Not Found [IP: 91.189.91.24 80]
Не удалось получить http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-7/icedtea-7-jre-jamvm_7u55-2.4.7-1ubuntu1~0.13.10.1_i386.deb  404  Not Found [IP: 91.189.91.24 80]
Не удалось получить http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-7/openjdk-7-jre-headless_7u55-2.4.7-1ubuntu1~0.13.10.1_i386.deb  404  Not Found [IP: 91.189.91.24 80]
Не удалось получить http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-7/openjdk-7-jdk_7u55-2.4.7-1ubuntu1~0.13.10.1_i386.deb  404  Not Found [IP: 91.189.91.24 80]
E: Невозможно получить некоторые архивы, вероятно надо запустить apt-get update или попытаться повторить запуск с ключом --fix-missing
Сегодня пробовал установить htop - эта же песня. Причём с ключом --fix-missing не могло найти ничего в течение 3 часов, я не  дождался, закрыл терминал.

[Yakov]

Я на ALT Linux так устанавливал JDK  Java8 -   http://zalinux.ru/?p=254
Так как в Сизифе его не было, там только Java 7 и 6.
Старую Java 7 я не удалял.

По идее, любую версию JDK можно поставить аналогично.

[serkondr]

Спасибо, попробую.

[serkondr]

На домашней машине I7-2600 4x3400MHz c 12G ОЗУ и свежеустановленной на чистый HDD системе Минт 17 х64
запустил HSQLDB-сервер с 4096 Гб под яву. Сервер успешно стартовал.
На этой же машине запустил клиента с адресом localhost и попробовал работать, одновременно наблюдая в системном мониторе.
Тормоза практически те же. Периодически упираются в потолок 100% линии загрузки ядер процессора. Память занята на 5,9 Гб постоянно.

[Yakov]

Тогда, похоже, дело не в выделении памяти для hsqldb, а в чём-то другом.

[serkondr]

Тормоза наблюдаю при выполнении сложных запросов с многочисленными связями между исходными таблицами и запросами. Впрочем отдельные запросы выполняются вполне быстро. Но вот когда эти запросы являются содержимым для форм, и особенно, когда есть цепочка субформ с такими запросами, то при изменении позиции указателя в основной форме, идёт по цепочке долгий пересчёт запросов во всех последующих субформах.

[Yakov]

А Apache OpenOffice 4.1.1 и LibreOffice 3.6, 4.4 пробовали?
Может быть, у них производительность больше будет чем у OpenOffice 3.3.0 ?

[serkondr]

На домашней машине вместе с минт 17 х64  стоит LOO 4.4.3.2. Именно из под него я и пробовал на тормоза 64-битную систему.
К сожалению, тормоза практически не поменялись. Может лишь чуть, т.к. сервер и клиент на одной машине без сети.
Вообще, несколько раз пробовал уйти от ООО 3.3.0, но нарывался на глюки. Кмк обе ветки офиса в процессе модернизации стали довольно сырыми. Поэтому возвращался к стабильной проверенной версии от Инфры.

[greenman]

Тормоза наблюдаю при выполнении сложных запросов с многочисленными связями между исходными таблицами и запросами.

Видимо, надо стремиться к использованию MEMORY tables. То, что у Вас таблицы в кеше, не даёт максимальной производительности. CACHED tables have a lower performance compared to MEMORY tables. - цитата из текста по ссылке, что я давал.

[serkondr]

А как мне проверить тип таблиц? 

Косвенно судя, могу предположить, что тип у меня всё-таки не CACHED, а MEMORY, если я правильно понимаю. Ведь если бы данные сохранялись и кешировались, то наверное обновлялись бы файлы БД.
Но данные, вводимые в БД у меня не сохраняются в файлах БД неделями. Т.е. на сервере в ОЗУ данные есть, а если сделать копию файлов БД и открыть их на другом сервере (дома например), то вижу, что там данные очень старые. Сделал специально задание в планировщик на сервере, чтоб команда checkpoint выполнялась 2 раза в сутки и не было потерь данных.

Причина загрузки процессора возможно в сложности построения моих форм.
В  формах у меня есть необходимость передавать данные из первой основной формы по связям иногда даже в последнюю субформу, с определением выбора данных по позиции указателя в каждой форме. Поэтому пришлось в запросах для субформ совмещать данные субформы и данные из предыдущей формы. Это приводит к тому, что количество строк в запросе следующей субформы вырастает в геом.прогрессии, т.к. оно умножается на количество строк в предыдущих  формах. Последний запрос получается из десятков тысяч строк, что и приводит в итоге к тормозам. Пока данных немного - мощность железа покрывает эту проблему. Данных стало много - упёрлось в 100% загрузки ядер.
Какое тут может быть другое решение - затрудняюсь. Может чего посоветуете?

[kompilainenn]

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

круто. возможно нужно оптимизировать структуру БД

[rami]

Какое тут может быть другое решение - затрудняюсь. Может чего посоветуете?

возможно нужно оптимизировать структуру БД

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

[serkondr]

Спасибо!

Пож-та рассмотрите мой первый вопрос, который меня сейчас волнует - то, что я описал про формы.

Если в первой (основной) форме, допустим таблица из 10 строк с номерами заказов, в последующей субформе - 850 строк с обозначениями узлов, каждый из которых соответствует одному из заказов. Между таблицами есть связь по № заказа.
При открытии формы, в первой таблице будет видно 10 строк, а во второй - только те строки из 850, которые соответствуют выбранной строке первой таблицы.
При выборе позиции указателя на одной из 10 строк первой формы, и далее на одной из строк субформы, в третью форму через связи должны попасть данные из выбранной строки основной формы (номер заказа) и данные из выбранной строки  второй формы (с обозначением узла).
В этой ситуации запрос для второй формы будет содержать 8500 строк, т.е. 10 раз по 850. Содержимое третьего запроса будет больше в число раз, соответствующее числу строк третьей формы (например 850 х 5 = 42500).

Добавлю, что содержимое запросов для форм у меня вычисляется достаточно сложно, там проверяется, что уже выдано, а что нет в соответствии с таблицами нормам расхода. Если всё выдано на заказ, номер заказа не отображается в первой форме. Если всё выдано на определённый узел, то его обозначение не отображается во второй форме.
В общем, процессору есть из-за чего напрягаться

Вот это - моя основная проблема с построением форм в виде последовательной цепочки таблиц с выбором позиции указателей. Как можно обойти эту геометрическую прогрессию записей  в запросах?