|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Решил тут поэксперементировать с большими чанками. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
т.е. скорость составила чуть больше гигабайта в минуту. Скажите, это нормально? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 14:03 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
17мег/сек для некоторых дисковых систем нормально, для обычного сата винта без нагрузки под одним пользователем нормально 40-70 мб/сек. Я только что копировал файлы на рейде с батарейкой и кешем, он показывал 20 мб/с это тоже нормально, ибо он нагружен другими процессами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 14:08 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Спасибо, а то я уж начал немного нервничать. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 14:11 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
360ГБ не пробовал обычно по 10Гб - секунды на сырых устройствах на Sun Solaris Насколько я понял - вы на линуксе, м.б. там это и нормально. на RHL 4 на raw тоже быстро все создавалось. такое впечатление что вы делаете на ф.с. Собственно это и одна из причин почему использую сырые. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 16:16 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
victor16Решил тут поэксперементировать с большими чанками. Код: plaintext 1.
т.е. скорость составила чуть больше гигабайта в минуту. Скажите, это нормально? А разве вы инициализировали не два раза по 360Г (включая зеркало) ? тогда получится уже 2,2 Г в минуту или 36Мб в сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 17:18 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Девайсы на 25 Gb инициализируются пару секунд на AIX. Попробуй использовать параметр DIRECT_IO для файлов, может будет побыстрее. Еще журналирование ФС также влияет на скорость, если чанки на файлах. Т.е. надо смотреть что за тип журналирования применяется в ФС, и нет смысла дважды журналировать сначала на уровне базы а потом на уровне файловой системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 17:21 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Вообще-то, для Informix лучше использовать raw-device .... и не только под SUN ... :) Ответ Art.Kagel: -------------------------------------- OK reading the White Paper (the 3rd link below) several things are clear: - JFS2 is a fairly light weight journaled filesystem since it only journals meta-data - It would appear that it is safe to use (unlike EXT4 and EXT3 with write-back enabled). - If you use JFS2 for IDS chunks you must either create the filesystem with 2K alignment or 4K alignment. If you use 4K alignment you must not use dbspace pagesizes that are not multiples of 4K. - You must mount the FS (or at least the directory containing the chunk files) with Concurrent IO (CIO) enabled in order to get decent performance compared to RAW. - IBM's own testing using Oracle for OLTP benchmark loads shows that using JFS2 with CIO enabled and FS alignment correct is about 8% slower than using RAW chunks and that just using Direct IO (DIO) with proper FS alignment is as much as 70% slower than RAW which is MUCH worse than the 25-40% I have tested over the years with traditional non-jounaled filesystems. From the second White Paper which tests CIO and DIO using DB2 UDB we learn: - Using Direct IO (DIO) on JFS2 is only efficient if the filesystem is NOT enabled for large files. So here we are back to 2GB or smaller chunks. - CIO on large file enabled FSs is OK. - The test was IO bound as the disk farm had insufficient bandwidth to satisfy the tests IO demands. - Here CIO comes much closer to RAW but IB that's only because the test was IO bound. Personally I am going to continue to recommend that we avoid all journaled file systems forchunks. I still think that RAW is the best way to go and that if one must use a filesystem it should be the simplest filesystem available that supports DIO. -------------------------------------- Интересный материал на данную тему: http://www.ibm.com/developerworks/library/l-journaling-filesystems/index.html Improving Database Performance With AIX Concurrent I/O https://www-03.ibm.com/systems/resources/systems_p_os_aix_whitepapers_db_perf_aix.pdf As for benchmarking, there is an IBM document about CIO/DIO etc.: http://www.ibm.com/developerworks/data/library/techarticle/dm-0408lee/ And another one: https://www-03.ibm.com/systems/resources/systems_p_os_aix_whitepapers_db_perf_aix.pdf ---------- С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 18:03 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
zaiets Насколько я понял - вы на линуксе, м.б. там это и нормально. на RHL 4 на raw тоже быстро все создавалось. такое впечатление что вы делаете на ф.с. Если речь идет о Linux то /dev/sdb & /dev/sdc не raw, это блочные устройства. Ядро к нем применяет такую же буферизацию как и обычным файлам, только служебных структур файловой системы ( инодов) там нет. 2 victor16 Почему используются не файлы ? Или если хочется raw, то не не через /etc/sysconfig/rawdevices или http://magazine.redhat.com/2008/09/17/tips-and-tricks-how-do-i-add-raw-device-mapping-in-red-hat-enterprise-linux-5/] udev ? Подключая блочные устройства в Linux Вы ничего не выигрываете по сравнению с файлами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 18:15 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
onstat- Подключая блочные устройства в Linux Вы ничего не выигрываете по сравнению с файлами. я б так категорично не утверждал. но как по мне и не теряем ничего. Как говорят - каждому свое. Пару раз повозившись на линухе с ф.с. - на ext2 сервер работал быстрее и пару раз аварийно положив ОС, пришел к выводу - что мне дешевле гемор с сырыми (lvm + raw) чем с ф.с. Те, кому привычно работать с ф.с. - не спорю, лучше себя будут чувствовать с ф.с. и сырые устройства им покажутся большим геморроем(мне линукс и AIX кажутся иногда сплошным геморроем - не крещусь принципиально :) ). Кстати, на RHL 5 на котором уже нет отдельной службы для raw, тоже все было делом секунд хотя и работали типа с блочными устройствами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.06.2009, 19:55 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
zaietsonstat- Подключая блочные устройства в Linux Вы ничего не выигрываете по сравнению с файлами. я б так категорично не утверждал. но как по мне и не теряем ничего. Я не категоричен, и никому не навязываю свою точку зрения. Поправлюсь : В производительности не теряем и не выигрываем, в удобстве по сравнению с файлами теряем. zaiets Как говорят - каждому свое. Пару раз повозившись на линухе с ф.с. - на ext2 сервер работал быстрее и пару раз аварийно положив ОС, пришел к выводу - что мне дешевле гемор с сырыми (lvm + raw) чем с ф.с. На блочный устройствах под Linux можно поиметь тот же геморой, потому что их кеширует ядро, точно также как и ФС. По поводу быстрее вопрос спорный, чем больше индексного поиска в базе , тем хуже производительность с кешированием в ОС. Если нужно больше полных сканирований , то ситуацию можно подправить параметрами упреждающего чтения в informix. zaiets Те, кому привычно работать с ф.с. - не спорю, лучше себя будут чувствовать с ф.с. и сырые устройства им покажутся большим геморроем(мне линукс и AIX кажутся иногда сплошным геморроем - не крещусь принципиально :) ). Я сам большой сторонник использования raw ( character special device), но не блочных устройств. И вижу между block special device & character special device большую разницу По этому поводу даже документация Informix говорит( первое, что нагуглилось): Administrator’s Guide for IBM Informix Dynamic Server Version 9.3 p10.9 3. Verify that the operating-system permissions on the character special devices are c rw-rw----. zaiets Кстати, на RHL 5 на котором уже нет отдельной службы для raw, тоже все было делом секунд хотя и работали типа с блочными устройствами. Что такое тоже припоминаю , когда впервые поставил informix на Linux после SCO , ставил на блочные, чанки создавались быстро. Потом в процессе эксплуатации выгреб гемороя, ознакомился с матчастью и перебросил ссылки чанков с bsd на csd и этим порешались все проблемы . ДО этого на SCO разницы между bsd & csd не было никакой. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2009, 03:05 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Интересные тут мысли... Несколько слов об архитектуре системы: Hardware: сервер - IBM x3650 дисковый массив - DS3400 ОС - SUSE SLES SP2 with MPP IDS - IBM Informix Dynamic Server Version 11.50.FC4. Раньше для создания сырых устройств я использовал команду raw, сейчас решил обойтись без нее, поскольку если в системе присутствует библиотека libaio.so, то Informix, начиная с версии 10, может использовать диски и партиции напрямую, с получением дополнительных преимуществ от KAIO, надо лишь установить параметр DIRECT_IO. Поэтому, после обнаружения осью логических дисков от дискового массива (/dev/sdb и /dev/sdc) я их напрямую выделил для IDS. С уважением, Виктор ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2009, 08:20 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
Еще одно интересное наблюдение. Инициализация чанка такого же размера, но без зеркалирования занимает доли секунды. Неужели это создание зеркала требует столько времени? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2009, 10:03 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
victor16Интересные тут мысли... дисковый массив - DS3400 Может не совсем в тему но, Я тут некоторое время назад тестировал произовдительность на разных размерах блока ( страйпа) и параметров кеша на DS4300 & AIX. Пробовал тесты dd- шкой в блочных и сырых устройствах , при одинаковых тестах количество операций ввода вывода было разным. Производительность на csd была лучше. Еще одна вещь на которое обратил внимание, мультиблочное чтение никогда не возвращает больше одного страйпа за одну дисковую операцию. Установлено 16 К значит больше 16К за одну операцию не читается и не важно что там указано в параметрах упреждающего чтения. Если есть возможность попробуйте , будет полезно с точки зрения производительности подобрать параметры храниния на сторадже. з.ы. Я в DS -ках разочаровался. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2009, 16:35 |
|
Долго инициализируются чанки
|
|||
---|---|---|---|
#18+
onstat- з.ы. Я в DS -ках разочаровался. Тестами производительности на DS не занимался. Кстати, некоторые ДСки вроде делаются на той же самой платформе что и какие-то сановские массивы (по словам интегратора). Но, подсел на привычку руководства видеть все в процентах, в этом плане больше понравились Hitachi - там есть параметр отслеживания нагрузки на отдельный физ. диск. Смотришь - перевалило за 60 - значит беда с массивом. Можно конечно смотреть на другие показатели но так как-то сразу понятней. Но не понравилось управление лунами - переделать луны(решили поменять стратегию работы с чанками ) - ох как нехорошо получается на младших массивах - удаляется только последний добавленный. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2009, 16:55 |
|
|
start [/forum/topic.php?fid=44&tid=1607815]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
83ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 183ms |
0 / 0 |