|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
Приветствую всех!!! Помогите с следующей проблемой: На сервере RHEL 7.9 настроен Database gatewey 19, который коннектится к разным серверам MS SQL. При запуске разрабами одного из скриптов, который получает "большие" данные из MS SQL переполняется tmp раздел. Размер /tmp 100 Gb. Подскажите, может быть есть параметр в init gatewey, который отвечает за это или как еще можно решить данную проблему? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 12:00 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
Javl Размер /tmp 100 Gb. Увеличивать уже пробовали? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 13:27 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
SQL*Plus, 100 гигов для /tmp не мало, сделаем к примеру 500 Gb не хватит, тогда что делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 14:11 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
При современных объемах 100 ГБ - относительно немного. Не хватит - тогда надо бы изменить скрипты, разделить крупные транзакции на более мелкие. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 14:15 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
dmdmdm При современных объемах 100 ГБ - относительно немного. Не хватит - тогда надо бы изменить скрипты, разделить крупные транзакции на более мелкие. Разработчиков трудно контролировать, мало того, не всегда понятно сколько человек и кто использует эти линки. Понятно, что возможно придется это делать, по этому я и хотел узнать, возможно есть более расширенные настройки, т.е. возможность регулировать какой объем данных идет через гетвей и как-то более гибко использовать ресурсы сервера, на котором развернут Database Getwey, переложить нагрузку на сервера с MS SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 14:20 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
Javl На сервере RHEL 7.9 настроен Database gatewey 19, который коннектится к разным серверам MS SQL. При запуске разрабами одного из скриптов, который получает "большие" данные из MS SQL переполняется tmp раздел. Размер /tmp 100 Gb. Древняя багофича dg4msql - он хранит в /tmp результаты подзапросов. Вариантов решения два: 1) Убедить/заставить разраба переписать SELECT'ы избегая вложенных подзапросов 2) Перенаправить эти временные файлы на другой том и увеличить его ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 15:08 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
leonx2 Javl На сервере RHEL 7.9 настроен Database gatewey 19, который коннектится к разным серверам MS SQL. При запуске разрабами одного из скриптов, который получает "большие" данные из MS SQL переполняется tmp раздел. Размер /tmp 100 Gb. Древняя багофича dg4msql - он хранит в /tmp результаты подзапросов. Вариантов решения два: 1) Убедить/заставить разраба переписать SELECT'ы избегая вложенных подзапросов 2) Перенаправить эти временные файлы на другой том и увеличить его Я читал, что якобы есть фикс, но это относится к 12 версии, а у нас 19 установлена, по идее там должен быть уже применен этот фикс. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 15:47 |
|
Переполнение tmp при использовании Database gatewey!
|
|||
---|---|---|---|
#18+
Javl Я читал, что якобы есть фикс, но это относится к 12 версии, а у нас 19 установлена, по идее там должен быть уже применен этот фикс. Патчи были для dg4msql версии 11.2 - они действительно сильно уменьшали объём файлов в /tmp. Но, до нуля, увы, не осилили. В 12.2 эти патчи вошли в базовый релиз. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2022, 16:14 |
|
|
start [/forum/topic.php?fid=52&msg=40136702&tid=1879482]: |
0ms |
get settings: |
7ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
45ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
185ms |
get tp. blocked users: |
1ms |
others: | 8ms |
total: | 260ms |
0 / 0 |