CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

23.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2003 г

    Настройка сервера базы данных Oracle и Linux

    Берт Скалзо , Oracle Magazine
    (Tuning Oracle Database Server and Linux,
    by Bert Scalzo)

    Источник: Oracle Magazine, articles online only, http://otn.oracle.com/oramag/webcolumns/2002/techarticles/scalzo_linux01.html

    Часть 1: Некоторые простые способы повышения производительности Oracle 8i под Linux

    Использованные средства

    • Сервер базы данных Oracle8i, Выпуск 3 (8.1.7);
    • Linux 6.2 Red Hat и
    • Quest Software's Benchmark Factory 3.0.

    Чтобы использовать эти технологии, вы должны обладать достаточными знаниями как в администрировании базы данных Oracle, и в управлении операционной системой Linux (или родственной ей UNIX). Но независимо от того, являетесь ли Вы официальным АБД и сисадмином UNIX, или просто АБД и "новичком" в Linux, основные советы и методы, приведенные здесь, сэкономят вам много времени. К числу рассматриваемых вопросов относятся установки файла параметров базы данных Oracle, версии ядра Linux, установки ядра и ключи трансляции, а также опции расширенной файловой системы и компилятора.

    Сегодня меня, как и многих людей, приводит в восторг продвижение Linux, не только потому, что я в основном являюсь администратором базы данных на UNIX, но также и из-за той удивительной скорости, с какой такие основные производители, как Dell, HP/Compaq, IBM и Oracle, ухватились за эту открытую в исходных кодах операционную систему. В прошлом июле на выставке LinuxWorld Ларри Эллисон объявил, что к концу года все внутренние бизнес-системы в корпорации Oracle будут эксплуатироваться на Linux-кластерах (http://otn.oracle.com/techblast/archive/june2002.html) , что доказывает, что Linux – не просто преходящее увлечение.

    Но что, если вы все еще эксплуатируете Oracle8i, и не совсем готовы к RAC (http://otn.oracle.com/products/oracle9i/pdf/rac_building_ha_rel2.pdf) (Real Application Clusters)? Должно удостовериться, что "выжали из репы все – до последней капли", когда мы развертываем Intel-серверы с Linux, особенно в тех случаях, когда базы данных Oracle эксплуатируются в промышленном режиме. Верите вы этому или нет, но весьма просто добиться повышения производительности базы данных на 1 000 процентов, если надлежащим образом настроить и сконфигурировать базу данных для Linux.

    В этой статье я сделаю обзор некоторых подходов, обеспечивающих высокую окупаемость инвестиций (ROI - return-on-investment). Вы увидите, что по ставшему промышленным стандартом эталонному тесту от TPC (Transaction Processing Performance Council - Совет по средствам обработки транзакций) время загрузки тестовой базы данных улучшилось на 1 015 процентов, а число выполняемых за секунду транзакций увеличилось больше, чем на 45 процентов. Это в 10 раз быстрее по загрузке данных, и почти вдвое выше по скорости транзакций – на тех же самых аппаратных средствах. В части 2 этой серии мы углубимся в более “темные” и трудные методы. [От редакции OM/RE: перевод второй статьи этой серии будет опубликован в следующем номере нашего журнала. ]

    Установка эталонного теста

    Ниже я приведу методы настройки управляемой среды, для которой я смог построить базовую конфигурацию, идентифицировать все поддающиеся изменению релевантные переменные, а также менять каждый раз по одной переменной и получать надежное измерение эффекта этого одиночного изменения.

    В качестве тестовой среды я использовал четырехпроцессорный сервер Compaq с 512 МБ памяти и восемью ультра-широкими SCSI-дисками со скоростью 7 200 оборотов в минуту. Затем я провел точно те же самые испытания с однопроцессорной системой Athlon с тем же самым объемом памяти, но всего лишь с одним ультра 100 IDE-диском со скоростью 7 200 оборотов в минуту. Хотя полученные в результате опытов (сырые – raw) цифры и проценты не были идентичными, наблюдавшаяся мной модель усовершенствования была следующей: каждое испытание делало каждую систему лучше в том же самом общем направлении и на подобные величины.

    Серверы Linux чрезвычайно гибки и просты в использовании в качестве Web-серверов, серверов приложений, баз данных, электронной почты, для работы с файлами и печати, а также как маршрутизаторы, экраны межсетевой защиты и комбинаций перечисленных выше функций. Для того, чтобы удовлетворить мое требование об изменении одной переменной за раз, я ограничусь только одним использованием. В следующей статье, я рассмотрю и другие использования.

    Для простоты при моих испытаниях я использовал эталонный тест TPC-C. Он широко признан как надежный эталонный тест рабочей нагрузки при онлайновой обработке транзакций (online transaction processing – OLTP). Этот тест справляется и с онлайновыми, и с отсроченными транзакциями, он неоднороден по природе, и его можно применять для множества баз данных – в том числе для всех выпусков баз данных Oracle. Вдобавок, вы можете конфигурировать TPC-C так, чтобы подчеркнуть все аспекты аппаратных средств: центральный процессор, память, шина и диск. И, чтобы быть до конца искренним, я – администратор базы данных в Quest Software, а наша компания производит полезную утилиту Benchmark Factory, которая определяет, выполняет и измеряет результаты испытаний TPC столь же простым образом, как если бы это была посылка электронной почты. На Рисунке 1 показан интерфейс Benchmark Factory: вы создаете проект эталонного теста TPC-C, определяете параметры, например, размер базы данных и число параллельно работающих пользователей, копируете тесты, которые хотите измерить для выполнения очереди, выполняете испытания в очереди и наблюдаете результаты.

    Рисунок 1: Интерфейс Benchmark Factory

    Я говорил, что буду рассматривать некоторые подходы с высоким коэффициентом окупаемости инвестиций. Это означает, что я буду искать элементы, настолько простые и очевидные в терминах применимости и воздействия, что мне достаточно будет всего лишь увидеть различия во времени выполнения TPC-C, чтобы понять, что я нахожусь на верном пути. Так что я буду рассматривать только то, что я называю низко висящими яблоками (low-hanging fruit) операционной системы и базы данных. В последующих статьях мы углубимся в изменения, для которых будут требоваться такие инструментальные средства Linux, как, например, команды free, iostat, ipcs, mpstat, sar, top и vmstat.

    Для многих АБД следующий раздел будет просто освежением некоторых очевидных (или, возможно, "не слишком очевидных") вопросов, связанных с конфигурацией и настройкой базы данных.

    Легкое достижение высокой производительности сервера базы данных (низко висящие яблоки)

    Я начну с рассмотрения типичного создания базы данных. Люди часто начинают с задаваемой по умолчанию базы данных, созданной при помощи Oracle Installer, или с базы данных, которая была создана Database Configuration Assistant. Как бы то ни было, параметры по умолчанию, вообще говоря, довольно не оптимальны. Но АБД-новичок или консультант, выдающий себя за АБД, может выбрать такие значения, которые сделают ситуацию еще хуже. Дело в том, что базы данных, созданные с плохими параметрами инициализации и использующие табличные пространства для словаря данных подобно тому, как это показано в Таблице 1, встречаются не так уж редко.

    Таблица 1: Типичные начальные параметры настройки базы данных
    Размер блока базы данных 2 КБ
    Буферный кэш SGA 64 МБ
    Разделяемый пул SGA 64 МБ
    Журнальный буфер в SGA 4 МБ
    Файл журнала регистации событий 4 МБ

    Табличные пространства

    Управление по словарю

    Результаты TPC-C (первичные значения)
    Время загрузки (сек) 49,41
    Транзакций/сек 8,152

    Очевидно, что самым первым должно стать увеличение размера SGA. Поэтому я увеличиваю буферный кэш и разделяемый пул, как показано в Таблице 2.

    Таблица 2: Увеличение размера буферного кэша и разделяемого пула
    Размер блока базы данных 2 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 4 МБ
    Файл журнала регистации событий 4 МБ
    Табличные пространства Управление по словарю

    Результаты TPC-C

    Время загрузки (сек) 48,57
    Транзакций/сек 9,15

    Это не совсем то, на что я не надеялся, так как улучшение времени загрузки произошло всего лишь на 1,73 процента, а увеличение скорости транзакций (transactions per seconds – TPS) на 10,88 процента. Возможно, я должен был увеличить и журнальный буфер в SGA, но я не хочу, чтобы журнал регистации событий был меньше, чем память, распределенная под SGA, так что я должен увеличить размер файла журнала регистации, как показано в Таблице 3.

    Таблица 3: Увеличение размера журнального кэша SGA и файла журнала регистации
    Размер блока базы данных 2 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 16 МБ
    Файл журнала регистации событий 16 МБ
    Табличные пространства Управление по словарю

    Результаты TPC-C

    Время загрузки (сек) 41,39
    Транзакций/сек 10,09

    Похоже, что теперь я что-то нащупал. Обратите внимание, время загрузки улучшилось на 17,35 процента. А скорость транзакций улучшилась примерно на такую же величину, как и прежде – на 9,33 процента. В этом есть смысл, так как для загрузки и одновременных вставок, обновления и удаления нужно намного больше памяти, чем 8 МБ. Похоже, что увеличение выделения памяти приводят к очень малым усовершенствованиям. Кажется, проблема возникает из-за ввода/вывода, так что несмотря на то, что я работаю с системой OLTP, я буду пробовать увеличить размер блока, как показано в Таблице 4.

    Таблица 4: Увеличение размера блока до 4 КБ
    Размер блока базы данных 4 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 16 МБ
    Файл журнала регистации событий 16 МБ
    Табличные пространства Управление по словарю

    Результаты TPC-C

    Время загрузки (сек) 17,35
    Транзакций/сек 10,18

    Вот теперь у меня все кипит! Даже на PC с его ограниченными возможностями шины и ввода/вывода, можно пожинать огромные выгоды от большего размера блока. Время загрузки улучшилось больше чем на 138 процентов без вреда для TPS. Предположим, мне не хочется снова увеличить размер блока. Тогда следующая простая идея, которая приходит на ум, это переключиться с табличных пространств, управляемых по словарю, на локально управляемые табличные пространства, потому что Oracle довольно интенсивно рекламировал их. Я заканчиваю с результатом, показанным в Таблице 5.

    Таблица 5: Использование локальных табличных пространств
    Размер блока базы данных 4 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 16 МБ
    Файл журнала регистации событий 16 МБ
    Табличные пространства Локальное управляение

    Результаты TPC-C

    Время загрузки (сек) 15,07
    Транзакций/сек 10,43

    Итак, Oracle прав – локально управляемые табличные пространства – это, определенно, правильное направление. Я получил более чем 15-процентное улучшение времени загрузки, и приблизительно на 2 процента выросла TPS. Но в действительности я хотел бы получить результаты, которые больше похожи на результаты для размера блока 4 КБ. Я попробую 8 КБ, как в Таблице 6.

    Таблица 6: Увеличение размера блока до 8 КБ
    Размер блока базы данных 8 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 16 МБ
    Файл журнала регистации событий 16 МБ
    Табличные пространства Локальное управляение

    Результаты TPC-C

    Время загрузки (сек) 11,42
    Транзакций/сек 10,68

    Не так уж плохо. Как и прежде, больший размер блока привел к улучшению времени загрузки (почти на 32 процента) без вреда для TPS. На самом деле TPS улучшилась больше, чем на 2 процента. Но заметьте, что я достиг критического положения дел с увеличением размера блока. Улучшение времени загрузки значительно уменьшилось (от 138 до 32 процентов), а увеличение TPS было почти в три раза больше, чем для размера блока 4 КБ. Дальнейшие увеличения размера блока вряд ли будут хорошим источником очевидных (настолько очевидных, что мне не нужно было использовать другие средства измерения производительности) достижений.

    Так что у меня быстро подходят к концу низко висящие яблоки базы данных. Единственная другая мысль, которая приходит на ум: у меня ведь имеется несколько центральных процессоров, так, может быть, я могу создать подчиненные процессы ввода/вывода, чтобы использовать их, как в Таблице 7.

    Таблица 7: Использование подчиненных процессов ввода/вывода
    Размер блока базы данных 8 КБ
    Буферный кэш SGA 128 МБ
    Разделяемый пул SGA 128 МБ
    Журнальный буфер в SGA 16 МБ
    Файл журнала регистации событий 16 МБ
    Табличные пространства Локальное управляение
    dbwr_io_slaves 4
    Lgwr_io_slaves (вторичных) 4

    Результаты TPC-C
      Время загрузки (сек) Улуч-шение Транзак-ций/сек Улуч-шение
    Результаты теста 1 49,41 N/A 8,15 N/A
    Результаты теста 2 48,57 1,73 9,15 10,88
    Результаты теста 3 41,39 17,35 10,09 9,33
    Результаты теста 4 17,35 138,56 10,18 0,89
    Результаты теста 5 15,07 15,13 10,43 2,36
    Результаты теста 6 11,42 31,96 10,68 2,42
    Результаты теста 7 10,48 8,97 10,72 0,32
    Общий результат 19,48 371,47 10,72 23,93

    Низко висящие яблоки Linux

    Теперь давайте посмотрим на повышение производительности операционной системы Linux, которая является достаточно интеллектуальной, чтобы распознать и адаптироваться к аппаратным проблемам, типа фирмы-изготовителя, скорости и числа центральных процессоров, количества системной памяти, а также типа, скорости и количества дисковых устройств. Тем не менее, остаются пригодными для использования многие неочевидные возможности повышения производительности. В данном случае я начну с типичной инсталляции Red Hat Linux 6.2. (Примечание: я начну работу с ядра 2.2.14-5smp, которое поставляется с Linux 6.2.)

    Первым заданием после установки Linux должно быть создание монолитного ядра (то есть повторная компиляция ядра для статического включения библиотек, которые вы намереваетесь использовать и отключения динамически загружаемых модулей). Идея заключается в том, что маленькое ядро, куда включены только те опции, в которых вы нуждаетесь, превосходит “жирное” ядро, поддерживающее функции, которыми вы все равно не пользуетесь. Так что я собираюсь использовать команду cd для изменения каталога на /usr/src/Linux и издам команду очистки xconfig (загрузившись для этого в интерфейс командной строки вместо системы X-Windows).

    Теперь я должен установить буквально сотни параметров. Я могу рекомендовать для использования любую из дюжины хороших книг или Web-сайтов по этой теме. Тот сайт, которым я пользовался чаще других, называется Securing and Optimizing Linux: Red Hat Edition (Обеспечение безопасности и оптимизация Linux: редакция Red Hat) Герхарда Моурани (Gerhard Mourani). (Вы можете также загрузить более старую версию книги Моурани в формате PDF (PDF version http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3.pdf ). Можно также посетить список OTN Members Booklist on Amazon (http://www.amazon.com/otn\), где можно найти другие рекомендованные книги по Linux).

    К числу немногих установок параметров, которые задержались в моей памяти, относятся тип центрального процессора, поддержка симметричной многопроцессорной обработки (SMP), поддержка APIC (Advanced Peripheral Interrupt Controller – усовершенствованного программируемого контроллера прерываний), поддержка DMA (прямого доступа к памяти), активация значения по умолчанию IDE DMA и поддержка квот. Мой совет – нужно пройти их все, а если у вас возникли какие-то сомнения – читать справочный файл xconfig,.

    Поскольку я знаю, что я собираюсь перекомпилировать ядро, я мог бы также исправить установки параметров взаимодействия процессов (IPC), как это записано в руководстве по установке базы данных Oracle. Для ядра 2.2, установки параметров общей памяти расположены в каталоге /usr/src/Linux/include/asm/shmparam.h. Я предлагаю установить значение параметра SHMMAX не менее 0x13000000. Параметры настройки семафора расположены в каталоге /usr/src/Linux/include/Linux/sem.h. Я рекомендую установить SEMMNI, SEMMSL и SEMOPN, равными, по крайней мере, 100, 512 и 100, соответственно.

    Теперь я перекомпилирую ядро, используя команду make dep clean bzImage, скопирую карту ссылок и образ ядра в мой каталог начальной загрузки, отредактирую /etc/lilo.conf, выполню lilo и перезагружусь. Если я все сделал правильно, машина загрузится, используя мое новое (более экономное и более скромное) ядро.

    Применение монолитного ядра с должным образом выставленными установками параметров IPC улучшает загрузку почти на 10 процентов, а TPS – почти на 7 процентов, как показано в Таблице 8.

    Таблица 8: Результаты TPC для монолитного ядра с должным образом выставленными установками параметров IPC
    Время загрузки (сек) 9,54
    Транзакций/сек 11,51

    Если простая перекомпиляция определенной версии ядра может привести к таким улучшениям, то, наверное, стоит задуматься, а не может ли обеспечить новые усовершенствования более свежая версия ядра из того же самого семейства. На Linux Interactive я нашел исходный код последней стабильной версии ядра того же самого семейства (в моем случае, 2.2.16-3smp). Но в результате я получил совершенно несерьезные усовершенствования – 1,5 процента для загрузки и фактически ничего для TPS, как показано в Таблице 9.

    Таблица 9: Результаты TPC-C для более новой (младшей) версии ядра
    Время загрузки (сек) 9,40
    Транзакций/сек 11,52

    Поскольку многие дистрибутивы Linux теперь используют в качестве основы ядро 2.4.x, следующим я попробовал именно его. Я загрузил исходный текст ядра 2.4.1smp (сегодня наиболее устойчивый выпуск – 2.4.7). Новое ядро стоило времени, потраченного на ожидание. Оно привело к усовершенствованию времени загрузки почти на 13 процентов и больше, чем на 10 процентов увеличило TPS, как показано в Таблице 10.

    Таблица 10: Результаты TPC-C для новейшей главной версии ядра
    Время загрузки (сек) 8,32
    Транзакций/сек 12,82

    Эти результаты не плохи, но настройка ОС должна обеспечить намного больший успех, типа того, что было, когда я настроил базу данных. Когда я настроил различные параметры базы данных, я выяснил, что те элементы, благодаря которым уменьшился ввод/вывод, скажем, размеры блоков и локальное управление табличными пространствами, обеспечили большие усовершенствования. Так что, моя цель состоит в том, чтобы найти методику сокращения ввода/вывода в Linux. По умолчанию Linux обновляет для любого файла атрибут last-time-read (время последнего чтения), если с ним выполняется операция чтения, и делает это же при операциях чтения. На самом деле, меня совершенно не волнует, когда база данных Oracle в последний раз читала свои файлы данных, так что я могу выключить эту опцию. Это известно как установка атрибута файла noatime (подобная установка существует для Windows NT, 2000 и XP; используйте команду regedit, чтобы установить HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate).

    Если вы хотите сделать это только для файлов данных Oracle, задайте команду - chattr +A file_name. Если вы хотите сделать это для всего каталога, команда должна иметь вид - chattr-R +A directory_name. Но лучший метод состоит в том, чтобы отредактировать файл /etc/fstab, и для каждого его входа добавить к списку параметров файловой системы ключевое слово noatime (четвертый столбец). Ниже приводится пример файла /etc/fstab с этим изменением:

    LABEL=/   /      ext2  defaults,noatime 1 1
    LABEL=/boot /boot    ext2  defaults,noatime 1 2
    none    /dev/pts  devpts gid=5,mode=620  0 0
    none    /proc    proc  defaults     0 0
    none    /dev/shm  tmpfs  defaults     0 0
    /dev/hda2  swap    swap  defaults     0 0
    /dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro  0 0
    /dev/fd0  /mnt/floppy auto  noauto,owner   0 0

    Это гарантирует, что полный набор файловых систем выиграет от этой методики и, что более важно, эти установки будут сохранены в период между перезагрузками. Результаты весьма впечатляют – улучшения времени загрузки почти на 50 процентов и 8 процентов для TPS, как показано в Таблице 11.

    Таблица 11: Результаты TPC-C для атрибута файла noatime
    Время загрузки (сек) 5,58
    Транзакций/сек 13,884

    Другая область, имеющая отношение к вводу/выводу – это подсистема виртуальной памяти Linux, которая, как и многое другое в Linux, слишком управляема. Для повышения производительности файловой системы мне достаточно отредактировать файл /ect/sysctl.cong и добавить в него следующий вход:

    vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

    где, согласно /usr/src/Linux/Documentation/sysctl/vm.txt:

    • Первый параметр полностью управляет максимальным количеством грязных буферов в буферном кэше. “Грязный” здесь означает, что содержимое буфера еще должно быть записано на диск, в противоположность “чистому” буферу, о котором вы можете уже забыть. Установка этого параметра на высокое значение означает, что Linux может задержать запись на диск на долгое время, но это также означает, что он должен будет сделать за один раз большой объем ввода/вывода, когда системе станет не хватать памяти. Низкое значение разбрасывает дисковый ввод/вывод более равномерно.
    • Второй параметр – 1200 ndirty, который дает максимальное количество грязных буферов, которые bdflush может записать на диск за один раз. Высокое значение означает отсроченный, пульсирующий ввод/вывод, тогда как маленькое значение может вести к нехватке памяти, когда bdflush не “просыпается” достаточно часто.
    • Третий параметр – 128 nrefill, который определяет количество буферов, которые bdflush добавит в список свободных буферов при вызыве refill_freelist (). Необходимо заранее распределить свободные буфера, потому что буфера часто имеют другой размер, чем страницы памяти, и какая-то “бухгалтерия” должна быть проделана заранее. Чем больше их число, тем больше памяти будет потрачено впустую, и тем реже нужно будет выполнять refill_freelist ().
    • Четвертый параметр – это 512 refill_freelist (). Когда оказывается, что он становится больше, чем nref_dirt грязных буферов, “пробуждается” (или, если угодно, запускается – прим. пер.) процесс bdflush.

    Усовершенствования производительности – 26 процентов для времени загрузки и 7 процентов для TPS – показаны в Таблице 12.

    Таблица 12: Результаты TPC-C при установке bdflush
    Время загрузки (сек) 4,43
    Транзакций/сек 14,99

    Итак, вот каковы мои заключительные результаты – теперь требуется меньше 5 секунд, чтобы загрузить то, на что раньше требовалось 50 секунд, а вдобавок, я почти удвоил TPS. И помните, я не вел никакого мониторинга – все это были, главным образом, очевидные (как те яблоки, что низко висят) усовершенствования.

    Вот полная итоговая таблица полученных мной результатов
      Время загрузки (сек) Улуч-шение Тран-закций/сек Улуч-шение
    Тест 1 49,41 N/A 8,15 N/A

    Общий результат настройки базы данных

    10,48 371,47 10,72 23,93
    Результаты теста 8 9,54 9,85 11,51 6,9
    Результаты теста 9 9,40 1,49 11,52 0,10
    Результаты теста 10 8,32 12,98 12,82 10,09
    Результаты теста 11 5,58 49,10 13,88 7,70
    Результаты теста 12 4,43 25,96 14,99 7,37
    Общий результат 4,43 70,97 14,99 17,09
    Окончательный результат 4,43 1.015,35 14,99 45,61

    Это значит: Linux + База данных Oracle8i = скорость

    Подведем итоги

    Linux и сервер базы данных Oracle хорошо согласованы по мощности и конфигурируемости. Чтобы получить от ваших аппаратных средств оптимальную возможную производительность, вы должны настроить их до хорошо сбалансированного состояния, что не является слишком трудным делом, если использовать правильные инструментальные средства и методологию. И эти усовершенствования могут заставить ваши приложения выполняться на несколько порядков величины быстрее. Так что никогда не используйте Linux или базу данных Oracle “прямо из коробки” (не используйте при установке значения по умолчанию) – вы можете заставить ваши системы мурлыкать от удовольствия, затратив на это всего несколько минут усилия.

    Берт Скалзо (Bert.Scalzo@Quest.com) – архитектор программных продуктов компании Quest Software (http://www.quest.com/ ) (Ирвин, шт. Калифорния), которая предлагает решения для управления приложениями, чтобы максимизировать доступность критичных бизнес-приложений и немедленную окупаемость инвестиций (ROI). Берт имеет степени бакалавра наук, магистра наук и доктора философии в области информатики. Он работал АБД Oracle, начиная с Oracle 4, а в настоящее время он работает с базой данных Oracle9i.
     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...