andrey_anonymousРадикально поднимает скорость передачи по сети, особенно если сервер отдален от клиента на несколько хопов.
Вячеслав ЛюбомудровДаже если клиент на сервере ARRAYSIZE радикально повышает быстродействие больших выборок
Тут вопрос не столько в сетевых задержках, сколько в количестве вызовов FETCH и откуда они продолжаются
+

разница в размере пакета и кол-ве roundtrp'ов. На Ethernet огромные latency, и при переходе от 10 Mbit -> 100 M -> 1 G -> 10 G latency почти не уменьшается, а вот througinput вполне растет

orawishhollisterПробовали всеми возможными вариантами, и exp и sql*plus и jdbc и oracle client, больших различий нет
это симптом, того, что так пробовали, что оптимизировать и не пытались
так же +

на данном форуме пару лет назад про fetch size ребятам-программистам говорил, говорил.... на форуме... в почте - ноль толка. Они уже от отчаяния мне денег предложили ))) Тоже самое по телефону объяснил их менеджеру по продажам. Он хоть и не технарь, но за 10-15 мин. все понял.... Не знаю какие меры им были приняты - но проблема с производительностью по его словам решилась ))), а я за слово из 12 букв setFetchSize получил вполне приемлемую сумму )))

hollisterСпасибо за советы, установка параметра в JDBC драйвере FetchSize позволило достингнуть скорости 21 000 row/sec, то есть ускорение примерно в 7 раз.

Какая сетевая карта?

hollisterEXTRA_OPTION_ORACLE.defaultRowPrefetch = 90 000

Никогда Prefetch'ем в JDBC не пользовался, в свое время игрался, разницу по отношению к стандартному setFetchSize не увидел.

Т.ч. какой код у Вас используется для выгрузки - не очень понятно.

1. Профилировать Java код. Не факт, что тормозит на JDBC вызовах. Даже запись такого потока на локальный диск - уже не очень быстрая операция. По хорошему, забирать данные и отдавать/записывать на диск нужно в двух разных потоках.
2. Можно поиграться с настройками Net80, сетевой карты. Сколько-то десятков процентов выжать можно.
3. В случае многопроцессорной машины, можно попытаться прибить поток гвоздями к одному из ядер. Установка affinity для клиентского потока у меня до 2-х раз давала увеличение скорости работы по сети.

сферический хрусталь в вакуумени запроса ни кода хоть одного из вариантов выгрузки.
+

По Вашим сообщениям, можно только гадать на кофейной гуще или смотря в запотевший (от алкоголя ))) ) хрустальный шар.

ТоПробовали и Java и утилита exp и oracle client, примерно все одинаково.

то
есть ускорение примерно в 7 раз.


Писал свои утилиты загрузки данных в Oracle на OCI (железо было конца 90-х, сервер уровня Pentium Celeron 500, 100 M Ethernet) - добивался почти 90% загрузки CPU на сервере.

Писал свою утилиту Oracle -> PostgreSQL на JDBC - загрузка сети (1 G Ethernet) по версии Windows была на уровне > 30%, но вся работа была в один поток. Загрузка процов на серверах Oracle, PostgreSQL так же под >50% (железо не знаю, виртуалки)

IMHO & AFAIK теоретически, до достижения размера пакета примерно 32 Kb - рост скорости от увеличения fetch size должен быть практически линейным. Выше 32 K - можно наткнутся на проблемы конфигурирования OS (размер MTU и прочее и прочее)

Если увеличили fetch size на порядки, а рост скорости "в 7 раз" - это как-то странно.

Для Ethernet 100 Mb/s - наверное почти придел по скорости, для 1 G и тем более 10 G - без тюнинга OS даже близко к приделу по скорости для одного потока не подойти. IMHO & AFAIK.

Я бы все же:
1. Разбирался, что именно тормозит
2. Читать доки по настройке
3. Если проблема чисто "скачать данные" и табличка НЕ меняется и сервер супер-топовый - никто не мешает побить табличку на части и качать в несколько потоков. Теоретически, OS сама смултиплицирует поток данных в сети и в общем, общее увеличение throught input может получится. Это ЖУТКОЕ издевательство на железом
4. Перенести скачивание данных на сторону сервера. Loopback на locall host имеет на порядки меньший latency, чем сеть. Реализовать сервис выгрузки (наподобие expdb), на клиента передавать уже готовый результат (файл), можно даже его паковать. Если админы разрешат, никто не мешает даже реализовать данные "exp" как ф-цию БД (встроенный java, external function).
5. Никто не мешает объединить 3+4 в одном флаконе и выжимать 70-100% производительности сети, за счет надругательства над серверами.

IMHO & AFAIK Все советы из разряда https://heretics.wapper.ru/tavern/vredsov.htm . Т.к. прежде чем что-то делать, хорошо бы понять, что именно у Вас происходит и что именно Вам нужно.

hollisterТак загрузка в БД у нас достаточно быстрая, с этим проблем нет.

Все чудесатие и чудесатие. "Загрузка" значительно более сложная операция, чем выгрузка.

hollisterЕсли увеличили fetch size на порядки, а рост скорости "в 7 раз" - это как-то странно.

Видимо есть максимальный предел этого значения. разницы между 90 000 и 200 000 нет.

Это понятно, я так и сказал, "при размере пакета < 32 kb"

Если пакет становится > 32 Kb уже легко попасть на не эффективные настройки OS (MTU и прочее), Oracle (reсv_buf, send_buf и пр.), железа (Interrupt'ы и JumboFrames) и т.д.

AFAIK Но и при 32 Kb пакетах, Вы должны уже достаточно сильно сеть загружать. Т.ч. что именно у Вас "тормозит" по Вашему описанию совсем не понятно

Тормозить может:
1. Клиент забирающий данные - профилировать
2. Сеть и передача через TCP и JDBC
3. Собственно сервер

Даже 21 Mb/s (3*7) это приличный скорость, например, мой Windows на десктопном SSD при массовом копирование мелких файлов больше 7-8 Mb/s (диск/диск) не показывает ))) Т.ч. при таких потоках, не факт, что тормоз в сети.

Думаю, что 30-50 % загрузка сети это уже очень много (т.е. 1 G Ethernet = 50 Mb/s), т.е. выжать еще раза 2 ускорения можно, а дальше уже пинать железо ))) IMHO

Гадание на кофейной гуще.

Если проблема в процессоре, то где? На сервере или на клиенте? Какая загрузка.

Отпрофилировать Java приложение, посмотреть на чем стоит. Делов на один день максимум.