|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
beg-in-er, ну да ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 14:24 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
ViPRos, прочитал весь топик. Ну и задачи у Вас Сахават. Сколько ж база у Вас весит? Я уж не говорю про администрирование. Крайне рекомендую посмотреть на bcp. Скорость он даёт очень приличную. Если есть деньги смотрите в сторону новых SSD+секционирование+выжать максимум от tempdb. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 17:36 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Сахават, а сколько времени занимают пересчеты при изменениях? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 19:51 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Proga, я не могу заставить завод купить дорогостоящее оборудование наоборот - пытаюсь задействовать все иемеющиеся свободные мощности, но пока об этом рано) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 19:58 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
SeVaСахават, а сколько времени занимают пересчеты при изменениях? Изменение изменению рознь :) кое - что (та ж поломка станка в станочной группе) можно считать локально (если через какие то политики (сверхурочные, выходные и т.д.) можно компенсировать (если не получится то перерасчет длится до реперных плановых точек и по политикам принимается решение), при эскалации сообщения об изменении до реперных точек и дальше по фронту к перерасчетам могут подключится все больше и больше ресурсов но обычно перерасчет расчетная задача, то есть тут больше анализ имеющиегся графа основная проблема с хранением большого объема данных - при моделировании (формировании) портфеля на период (год - три - пять) по разным политикам (критериям) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 20:04 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
опять ж все это зависит от завода, от циклов производственных, от серийности и т.д. но в тех заводах какие я видел все смешано и электроника и мехобработка и сборкка и литье и вся фигня и большая кооперация (которую надо синхронизировать детально) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 20:07 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
вот пришел САП ми сказал - на каждый модуль нужен4 ядра с такими то характеристиками и стоко то чего то а у меня не получается дать заводам рекомендации, все зависит от ТП, от самого завода (есть ли проекты НИОКР, обытное производство и т.д.) но люди требуют оценить я изначально обещал что задейтвую все мощности в наличии и особо не буду требовать реструктрузации ИТ мощностей кроме может быть сетей но пока не смог так организвать прогу (не дошла очередь до этой части) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 20:13 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Меня раздирало любопытство и я решил попробовать утилиту bcp для быстрой загрузки данных в ms sql server 2008 r2. Условия тестирования те же что и для оракла в предыдущем посте. Те же винты, тот же файл Fixed CSV 1.6 Gb. Перечислю только специфичные штуки: Recovery Mode = Simple Триггеров нет Конкуренции нет Индексов нет По структуре таже табличка что и в oracle. Параметры команды bcp (batch size 100 000) Код: sql 1.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Ждал я ждал, пошел кофе заварил, сидел опять ждал. Дождался. StartTime: 23:27:05,77 FinishTime: 23:34:19,29 Итого bcp/sqlserver справились за 7 мин. Oracle делал это ~ 45 сек, а копирование того же файла 41 сек на моем компе. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 23:51 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Всего минут (данные со скрина вконце количество строк в секунду): 60170814 / 138988 = 432,92 / 60 = 7,2 минуты bulk insert != direct path insert ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2013, 23:58 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Lord British, отсюда Lord Britishbcp db2.dbo.t1 in data.csv -f t1.xml -e err.txt -U sa -P "pass" -b 100000 уберите Lord British-f t1.xml -e err.txt вообще не упало(мы ведь хотим скорости) и добавьте -h "TABLOCK", также можно попробовать -h "TABLOCKX", может накинет ещё чуть скорости ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2013, 09:31 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Proga, уберите -f t1.xml -e err.txt Не влияет вообще, кроме того, первый считывается в самом начале - это параметры откуда, что брать. А в err.txt ошибки должны сыпаться, но ошибок нет, так что. добавьте -h "TABLOCK" вот это уже ближе к истине, дело пошло лучше также увеличил в пять раз размер batch -b 500000 создал datafile с заранее выделенным местом и создал табличку с привязкой к этой файловой группе [src]bcp db2.dbo.t1 in data.csv -h "TABLOCK" -f t1.xml -e err.txt -U sa -P "pass" -b 500000 [/quote] 500000 rows sent to SQL Server. Total sent: 57000000 500000 rows sent to SQL Server. Total sent: 57500000 500000 rows sent to SQL Server. Total sent: 58000000 500000 rows sent to SQL Server. Total sent: 58500000 500000 rows sent to SQL Server. Total sent: 59000000 500000 rows sent to SQL Server. Total sent: 59500000 500000 rows sent to SQL Server. Total sent: 60000000 60170814 rows copied. Network packet size (bytes): 4096 Clock Time (ms.) Total : 69638 Average : (864051.44 rows per sec.) Итого: ~ 69.9 сек --- Oracle sqlldr за аналогичное время (другой тест) мог залить не fixed csv, т. е. с переменной длиной колонок и с разделителем колонок и столбцов. Мне не очень хотелось, чтобы большое время парса файла повлияло на общее время, так как с direct path API, этого бы не было и решил использовать fixed csv, я указал SQLLDR позиции данных в строке и длину строки в fixed csv, в этом случае он, использует адресную арифметику, а не ищет где там колонки или где там затерялся CRLF (дока рекомендует), в итоге ~ 45 сек. Собственно этот же файл fixed csv я тестировал и с ms sql server, но в доке ms sql, я нашел для файлов параметров только <FIELD ID="1" xsi:type="CharFixed" LENGTH="10"/> <FIELD ID="4" xsi:type="CharTerm" TERMINATOR="\r\n" /> есть ли возможность сказать bcp, чтобы он по оптимальнее с этим всем обходился в случае fixed csv? ps Vipross, вариант поюзать bcp api и поглядеть насколько быстро будет писать по мере генерации без накладных расходов с csv. Если кто будет делать - поделитесь результатами в сравнении с операцией копирования на ту же дисковую систему. bcp_batch bcp_bind bcp_colfmt bcp_collen bcp_colptr bcp_columns bcp_control bcp_done bcp_exec bcp_getcolfmt bcp_gettypename bcp_init ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2013, 10:29 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Lord British, ну есть SQLBulkCopy АДО пользуюсь, но медленно, попробую потом bcp api как токо будет время ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2013, 10:56 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Lord BritishProga, уберите -f t1.xml -e err.txt Не влияет вообще, кроме того, первый считывается в самом начале - это параметры откуда, что брать. А в err.txt ошибки должны сыпаться, но ошибок нет, так что. добавьте -h "TABLOCK" вот это уже ближе к истине, дело пошло лучше также увеличил в пять раз размер batch -b 500000 создал datafile с заранее выделенным местом и создал табличку с привязкой к этой файловой группе [src]bcp db2.dbo.t1 in data.csv -h "TABLOCK" -f t1.xml -e err.txt -U sa -P "pass" -b 500000 500000 rows sent to SQL Server. Total sent: 57000000 500000 rows sent to SQL Server. Total sent: 57500000 500000 rows sent to SQL Server. Total sent: 58000000 500000 rows sent to SQL Server. Total sent: 58500000 500000 rows sent to SQL Server. Total sent: 59000000 500000 rows sent to SQL Server. Total sent: 59500000 500000 rows sent to SQL Server. Total sent: 60000000 60170814 rows copied. Network packet size (bytes): 4096 Clock Time (ms.) Total : 69638 Average : (864051.44 rows per sec.) Итого: ~ 69.9 сек --- Oracle sqlldr за аналогичное время (другой тест) мог залить не fixed csv, т. е. с переменной длиной колонок и с разделителем колонок и столбцов. Мне не очень хотелось, чтобы большое время парса файла повлияло на общее время, так как с direct path API, этого бы не было и решил использовать fixed csv, я указал SQLLDR позиции данных в строке и длину строки в fixed csv, в этом случае он, использует адресную арифметику, а не ищет где там колонки или где там затерялся CRLF (дока рекомендует), в итоге ~ 45 сек. Собственно этот же файл fixed csv я тестировал и с ms sql server, но в доке ms sql, я нашел для файлов параметров только <FIELD ID="1" xsi:type="CharFixed" LENGTH="10"/> <FIELD ID="4" xsi:type="CharTerm" TERMINATOR="\r\n" /> есть ли возможность сказать bcp, чтобы он по оптимальнее с этим всем обходился в случае fixed csv? ps Vipross, вариант поюзать bcp api и поглядеть насколько быстро будет писать по мере генерации без накладных расходов с csv. Если кто будет делать - поделитесь результатами в сравнении с операцией копирования на ту же дисковую систему. bcp_batch bcp_bind bcp_colfmt bcp_collen bcp_colptr bcp_columns bcp_control bcp_done bcp_exec bcp_getcolfmt bcp_gettypename bcp_init можно попробовать поиграться с параметрами -t и -r, в BOL это статья Specifying Field and Row Terminators ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2013, 10:57 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Потестил ради интереса bcp api, прироста по сравнению с bcp + csv не много. Табличка таже, только генерируется и заливается программно те же 60 170 814 строк гавнакод на cpp Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
start time: 16:23:48,81 finish time: 16:24:51,06 ~ 63 сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2013, 16:31 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
ViPRosа на днях попался с TryGetValue кругом рекомендации, типа это говно быстрее, чем Contains и присовение вранье полное GC убивает все рекомендации на корню эт я типа решил прогу пересмотреть и оптимизировать код с помощью нововведений нах Эти нововведения - высокоуровневая надстройка над высокоуровневой надстройкой. От этого скорости вычислений не увеличиваются. Линк (и вообще весь Сишарп с Дотнетом) был придуман не для увеличения скорости вычислений, а для увеличения скорости разработки. Чтобы GC хорошо работал, ему нужен запас по свободной ОЗУ, в несколько раз превышающий потребление проги. Тогда не сильно тормозить будет. Что там у вас с ОЗУ на ноуте и потреблением? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 06:01 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
user7320, ну полгода прошло уже счас на "ноуте" 96 ядер, сотни г памяти и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 09:09 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
ViPRosuser7320, ну полгода прошло уже счас на "ноуте" 96 ядер, сотни г памяти и т.д. Вы снова тесты проводили, на новом (как я понимаю) железе, с лихвой памяти? И что, GC так же печален, или лучше стало? Я ссылку на статью приводил, где сказано, что в своём лучшем виде GC достигает 70% производительности натива. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 11:43 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
Кстати, а чем вы все эти секунды в тестах замеряете? Что за программа? Для Сишарпа и для С++. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 11:45 |
|
на что хоть нарвался?
|
|||
---|---|---|---|
#18+
user7320ViPRosuser7320, ну полгода прошло уже счас на "ноуте" 96 ядер, сотни г памяти и т.д. Вы снова тесты проводили, на новом (как я понимаю) железе, с лихвой памяти? И что, GC так же печален, или лучше стало? Я ссылку на статью приводил, где сказано, что в своём лучшем виде GC достигает 70% производительности натива. ну с TryGetValue замарачиваться больше не стал за памятью теперь ВИПРОС следит сама (по части загрузки данных) с записью больших данных в БД - самый лучший вариант для МС СКЛ оказался порционная запись с использованием пользовательских типов (insert Table (...) select (...) from &DataTable) где DataTable == System.Data.DataTable ну вроде все ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2013, 12:22 |
|
|
start [/forum/topic.php?fid=20&msg=38141187&tid=1404072]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
122ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 238ms |
0 / 0 |