|
Действия ...
Период между сообщениями больше года.
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
02.04.2004, 10:55
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Дано SunSolaris 9 ASE 11.9.2 Первая попытка создания базы чуть было не закончилась отказом от использования ASE: для DataBase Device были отведены RAW партишки, тестировалась на 8млн записей. Скорость заливки через BCP в таблицу с одинаковой структурой жутко низкая. Потом решили попробовать использовать файловые устройства (правда версии ниже 12 не работают с файлами > 2Gb, пришлось наплодить тучу файлов по 2Gb)/ Результат - разница по скорости в 32 раза выше... без комментариев. Вопрос к специалистам: Оптимизатор запросов, насколько я понял, работает используя статистику, которая кроме как руками или при создании не обновляется. В нашем случае обновление статистики приводит к немеряному увелечению времени выполнения, планы которые оптимизатор берет за best полный ацтой. Написание своего SQL запроса с принудительным указанием индесков и force прохождения значительно ускоряет работу (в худшем случае в 2 раза). Это у всех так или нет? Помогите, что этим делать? Базу надо отдать на расстрел юзерам, которым не будешь объяснять почему их SQL (в принципе правильный) работает меделеннее чем в Access`e ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 15:04
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
>Результат - разница по скорости в 32 раза выше... без комментариев. Люди, которые знают ASE получше меня уверяли, что надо обязательно использовать RAW device. Т.е. если не использовать журналирующей файловой системы вроде NTFS - все ясно, но почему-то в Unix нельзя использовать файлы даже с журналирующей FS - что-то говорили про асинхронный доступ (увы в тот момент не понял о чем речь). Вопрос к знатокам - стоит ли использовать файловые девайсы ? Может это зависит от версий Solaris и ASE? >Написание своего SQL запроса с принудительным указанием индесков и force >прохождения значительно ускоряет работу (в худшем случае в 2 раза). Это у >всех так или нет? У меня так. Оптимизатор в ASE - одно растройство :(((, увы это не Oracle. Он вобще-то работает, но сложность искуства общения с ним сравни ручному прописыванию индексов и хинтов. Часто помогает хинт - set forceplan on. >Помогите, что этим делать? Базу надо отдать на расстрел юзерам, которым >не будешь объяснять почему их SQL (в принципе правильный) работает >меделеннее чем в Access`e Еще с fox-ом сравни, ясно дело если ПК приличный, то Access и Oracle сделает. Серверные СУБД нужны для разделяемого доступа - поробуй сравнить, когда к Access обращаются хотя бы пользователей 10-20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 15:04
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
Почему именно 11.9.2? Как статистику апдейтили? Что за база? Сервер сам в конфиге настроен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 15:07
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Про настройки - ASE очень любит память. Какой объем данных в базе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:07
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
ASE 11.9.2 потомучто приехала с железом в комплекте Базу пока тестим на порядка 8млн. записей (планируется в 50-70 раз больше ежемесячно). Всего табличек, включая справочники ~20. Пользователей от силы будет человек 5 - информация закрытая. Таблицы с данными будут только вливаться, к записи цепляться id из таблицы набора признаков, которая собственно и является процедурно редактируемой. Сервер http://www.sun.com/servers/entry/v240/specs.html с двумя процами по 1,00Gh, двумя винтами по 36 (будем добивать до 4 Х 72) Соларис SunOs 5.9 Статистику обновляли - update all statistics и из Central`а тоже пробовали, по разному, индексы сносили, перестраивали, меняли наборы, че-то там еще для таблицы функция (типа grap или как-то так). Результат примерно один, хотя не всегда одинаковый. Единственная заковырка, которую пропустили при инсталяции - размер страницы ( по умолчанию остался ) - 2K/ Пока сходимся на мнении, что без переустановки его изменить нельзя, или мы ошибаемся? (Подчеркиваю версия 11.9.2 - serverdata -z не работает:( ) Ну и второй проц пока не юзаем - особой надобности нет пока с этим не разобрались. Для примера запрос Select a, b, id_bb from b (index id_bb) where id_bb in (3310,3311) шел ~20 минут. ЗЫ А forceplan только и спасает, но надо отдать на руки чтоб без него все работало ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:14
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
PPS Забыл про ОЗУ сказать - 2Gb Да вот просто полная инфа про сервак: *System Configuration: Sun Microsystems sun4u Sun Fire V240 System clock frequency: 167 MHZ Memory size: 2GB ==================================== CPUs ==================================== E$ CPU CPU Temperature CPU Freq Size Implementation Mask Die Amb. Location --- -------- ---------- ------------------- ----- ---- ---- -------- 0 1002 MHz 1MB SUNW,UltraSPARC-IIIi 2.4 - - MB/P0 1 1002 MHz 1MB SUNW,UltraSPARC-IIIi 2.4 - - MB/P1 ================================= IO Devices ... ============================ Memory Configuration ============================ Segment Table: ----------------------------------------------------------------------- Base Address Size Interleave Factor Contains ----------------------------------------------------------------------- 0x0 1GB 1 BankIDs 0 0x1000000000 1GB 1 BankIDs 16 Bank Table: ----------------------------------------------------------- Physical Location ID ControllerID GroupID Size Interleave Way ----------------------------------------------------------- 0 0 0 1GB 0 16 1 0 1GB 0 Memory Module Groups: -------------------------------------------------- ControllerID GroupID Labels -------------------------------------------------- 0 0 MB/P0/B0/D0 0 0 MB/P0/B0/D1 1 0 MB/P1/B0/D0 1 0 MB/P1/B0/D1 System PROM revisions: ---------------------- OBP 4.11.4 2003/07/23 08:04 Sun Fire V210/V240,Netra 240 OBDIAG 4.11.4 2003/07/23 08:05 * ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:16
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
1. Сразу видно, что Вы что-то намутили с сервером. 2. update all statistics совершенно не нужно выполнять. Апдейтится/создаётся статистика по всем колонкам (не только по тем, что входят в индексы). 3. В конфиг сервера смотрели или всё по дефолту стоит? 4. С временная базой разбирались? 5. Кэши создавали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:27
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Про сравнить при количестве пользователей: мы вдвоем запросы по очереди запускали - вместе бессмысленно... :((( Кеши создавали (сейчас юзается 2, 8, 16кб страницы, общий объем - 8,17Мб) update all statistic - от безысходности, раздельно по индексам пробовали... под временную базу отвели 4Гб - при запросе по DISTINCT влезла только в 5, в остальных запросах она не юзается КОнфиг базы смотрели и не один раз, целесообразного текущим задачам ничего не нарыли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:29
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
LogSegment c данными разнесены на разные винты. Какие еще мысли будут? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:39
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
Дык у Вас же один дефолтный кэш сейчас 8Mb и тот побит на пулы. Неудивительно, что сервер тормозит. Как он ещё не умер от такой безисходности? И индексы поэтому не юзаются и планы запросов кривые, потому, что оптимизатор при выборе индексов и планов учитывает не только статистику, но и есть ли в кэше индекс, достаточен ли по размеру кэш или нет. Срочненько разбирайтесь с дэфолтным кэшем и желательно отдельный кэш на базу tempdb. Вот и объяснение почему с сырыми устройствами тормоза были больше (сейчас хоть на файловой системе операции ввода/вывода кэшируются). Мда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:48
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Щас попробуем, но не в том замес О результатах сообщу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 16:59
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
У 11.9 насколько я помню вся свободная память автоматом отдается в 'default data cache', это уже в 12.0 поменялось, т.е настройте Sloaris, что бы отдавал где-то 1,5 Гб сторонним процессам (файл /etc/system, параметр set shmsys:shminfo_shmmax=сколько_не_жалко, в байтах) - описываю для Solaris 8, Solaris нужно перестартовать. В ASE настраиваем параметр max memory (в страницах - у вас 2кб). Желательно установить параметр allocate max shared memory в 1 - указываем серверу забирать всю память при старте. Рестрартуем ASE. Желательно создать отдельный кэш на tempdb - примерно на 150-200Мб. Кстати tempdb лучше делать как раз в файловом девайсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 17:49
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
сконфигурить cache со строны ASE не удалось, действительно версия ... Очень вовремя пришло FAQ от _Sania, будем добивать супастата ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 17:55
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Хм, стоит set shmsys:shminfo_shmmax=4Г ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 18:05
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Пока не настроишь max memory, кэши увеличить не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 18:07
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
автор Дано SunSolaris 9 ASE 11.9.2 Первая попытка создания базы чуть было не закончилась отказом от использования ASE: для DataBase Device были отведены RAW партишки, тестировалась на 8млн записей. Скорость заливки через BCP в таблицу с одинаковой структурой жутко низкая. Потом решили попробовать использовать файловые устройства (правда версии ниже 12 не работают с файлами > 2Gb, пришлось наплодить тучу файлов по 2Gb)/ Результат - разница по скорости в 32 раза выше... без комментариев. Если у скорость на фаловых устройствах в 32раза выше чем на сырых устройствах, очень похоже, что дело в кэше на операцию "запись". В случае файловых устройств ОС явно кэширует "запись". Это не безопасно, т.к. в случае сбоя (например, по питанию) данные застрянут в кэше и вы повредите базу. В случае сырых устройств кэш обычно включается на уровне RAID-контроллера. Его режим д.б "write-back", но не "write-through". Кроме этого для гарантии сохранности данных на RAIDе обязательно д.б. "батарейка". Если в вашем Sunе диски подключены к машине ч/з контроллер без апп. кэша, то конечно же, будет медленно (зато надежно). Общие рекомендации таковы: если в базе больше операций на модификацию (insert|update|delete) болшую скорость получите на сырых устройствах, если в базе преобладают select, тогда имеет смысл попробовать файловые устройства (но обязательно c dsync=on) Безопасное использование фаловых устройств вообще допускается только начиная с версии ASE 12.0, когда для файлового устройства в UNIX можно установить флаг dsync=on. Т.е. операция "запись" должна производится синхронно, минуя кэш ОС. автор Оптимизатор запросов, насколько я понял, работает используя статистику, которая кроме как руками или при создании не обновляется. Статистика есть 2х видов: табличная (размер таблиц, число записей, и т.п) и колоночная (плотность значений, гистограмма, и т.п). Табличная ст. обновляется автоматически hausekeeperом, колоночную нужно обновлять вручную : лучше всего при помощи update index statistics <tab>. автор В нашем случае обновление статистики приводит к немеряному увелечению времени выполнения, планы которые оптимизатор берет за best полный ацтой. Утверждение голословное. Нужно разбираться в причине. Скорее всего - проблемы с точностью статистики. Андрей Хромов Sybase CIS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 19:10
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Извини за неграмотность, но где искать max memory? в servername.cfg такого параметра нет Sp_config по memory выдает только Parameter Name Default Memory Used Config Value Run Value -------------- ------- ----------- ------------ --------- additional network memory 0 0 0 0 lock shared memory 0 0 1 1 memory alignment boundary 2048 0 2048 2048 memory per worker process 1024 0 1024 1024 shared memory starting address 0 0 0 0 total memory 14336 28672 14336 14336 больше ниче нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.04.2004, 19:22
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
total memory - оно и есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
03.04.2004, 15:07
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Guest прав, это он в 12.5 max memory. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.04.2004, 14:39
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Я на форуме человек новый, был приятно удивлен, что его посещают и участвуют в дискуссиях сотрудники Sybase CIS. Но оптимизатор что до-, что после- обновления статистики по индексам без принудительного указания пути и последовательности, выдает, мягко говоря, не верное решение. По поводу дисковых девайсов - чуть позже, дабы дать аргументированный, выверенный ответ. To _Sania & Guest Под Cache теперь 1,7 Gb из них 1Гб под default, 200Mb под tempdb Результат - запрос с 37,5 мин уменьшился до 33 Это стоило того!!! Ж) Что и требовалось доказать (см msg от 2 апр 04, 16:48) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.04.2004, 14:51
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
Это ещё не всё. Проверь теперь пулы в кэше(оставьте только 2к пул). Дальше (когда разберётесь) может будет иметь смысл добавить ещё и 16к пул (но не три - нет смысла). Дальше для своего тэстового запроса: Выполните update index statistics для таблиц из запроса. Выполните set showplan on set statitics io on set statistics time on Выполните запрос 2 раза. Если будете сюда постить сам запрос, то напишите и план, кол-во записей в таблице, индексы, размер таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
05.04.2004, 15:18
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
В догонку. Когда будете тэстить свой запрос, то посмотрите что творится вообще на сервере с помощью процедуры sp_sysmon ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.04.2004, 15:16
|
|||
|---|---|---|---|
|
|||
О размещении на RAW device и не только |
|||
|
#18+
Ты знаешь, даже писать не хочется Пошел второй месяц "работы" ... ... разбор оптимизатора по запчастям ни к чему не привел, пишем запросы руками, без его использования (если очень интересно могу выложить планы с описанием для одного и того же запроса наш/оптимизатора) А вообще почти махнули рукой на SyBase, подняли Velocies сейчас делаем базу, будем переливать данные, пробовать на нем. Потому как такого жуткого апломба (читай облома) по разным ограничениям/отсутствию/и т.д. давно никто не встречал (часть, конечно связана с версией, но не все) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.04.2004, 16:35
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
Могу понять. Я сам работал админом 2 года на 11.9.2. Сначала тоже было непонятно и многое тормозило, потом начал разбираться и приводить в порядок. Самый оригинальный из примеров: был написан одним из программеров запрос: select id,convert(varchar,104,dt) as dt from tab where ... order by dt По dt был кластерный индекс (табличка немаленькая). Так вот прелесть этого запроса была в том, что он выполняется немеренно долго и работает через временную таблицу. Заставил переписали так: select id,convert(varchar,104,dt) as dt_my from tab where ... order by dt и всё стало отрабатывать за милисекунды. Сервер вторую половину моей работы летал. Сейчас конечно если смотреть на 12.5, то много чего не хватало в 11.9.2 (например "sort merge join and JTC"). Так что скорее всего твои проблемы связаны с неопытностью с одной стороны ну и версия старовата уже с другой стороны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.07.2006, 13:56
|
|||
|---|---|---|---|
О размещении на RAW device и не только |
|||
|
#18+
GuestСамый оригинальный из примеров: был написан одним из программеров запрос: select id,convert(varchar,104,dt) as dt from tab where ... order by dt По dt был кластерный индекс (табличка немаленькая). Так вот прелесть этого запроса была в том, что он выполняется немеренно долго и работает через временную таблицу. Заставил переписали так: select id,convert(varchar,104,dt) as dt_my from tab where ... order by dt и всё стало отрабатывать за милисекунды. ПРобовал на АСЕ 12.5 выполнить: > select id,convert(varchar,104,dt) as dt from tab where ... order by dt >select id,convert(varchar,104,dt) as dt_my from tab where ... order by dt Действительно, второй вариант работает быстрее. Почему? Может быть дело в том что ОН сначало сортирует данные по полю 'dt' (convert(varchar,104,dt)) в WorkTable, а потом еще при итоговом выводе по 'as dt' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=55&tablet=1&tid=2012731]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 369ms |
| 0 / 0 |
