В новостях на ixbt.com проскочило сообщение о том, что "корпорация EMC выпустила новое решение для резервного хранения данных на жестких дисках - CLARiiON DL210". Все бы ничего, как обычно, да только этот массив емкостью до 24 терабайт построен на SATA-дисках емкостью по 500 гигабайт.
Я уже давно намекал, что пора бы в качестве среднего решения строить RAID на SATA. Понятно, что RAID 1/0 это баловство, можно устроить и у себя на рабочей станции. А вот RAID 5... Причем, в данном случае скупиться не надо, можно начинать строить такой массив не на трех, а минимум на четырех-пяти дисках.
Причем, эксперимент можно начать с дисков чуть ли не по $60, потому что даже такие уже имеют поддержку NCQ, и минимальный объем такого массива получится (4-1)*80гиг = 240 гигабайт, чего вполне достаточно и для баз данных, и для файлового сервера.
Правда, надежность SATA на порядок ниже, чем у SCSI. Однако, если свести теорию вероятности (и наработку на отказ) к известному анекдоту про вопрос мужчине и женщине "какова вероятность, что выйдя на улицу, вы увидите динозавра?", то в отношении SCSI остается лишь смутная уверенность, что "это лучше".
Например, у SATA II дисков Hitachi сейчас наработка на отказ - 1 ошибка на 10^14 операций. У SCSI-дисков той же фирмы, обратите внимание - 10 ошибок на 10^16 операций. Почему пишут именно так, а не "1 на 10^15" - непонятно.
Кстати, только что прочитал, что существует RAID5E, который надежнее всем известного RAID 5 (обратите внимание на упоминание spare drive) . Главное, чтобы такие контроллеры были доступны.
Хотя, может, я это зря пишу, и поставщики серверов уже давно наладили выпуск моделей "среднего класса" с RAID 5 на SATA II ?
p.s. чуть не забыл - спору нет, SCSI пока быстрее при "параллельной записи", чем SATA. Но думаю, что SATA еще даст жару.
26.4.06
12.4.06
Два или один
Спасибо всем за комментарии к "Жертвы тиража", думаю, к этой теме я обязательно вернусь, теперь уже по поводу самих разработчиков, зарплат, квалификации и т.п.
В этой заметке я хочу поделиться мыслями по поводу "двухъядерных" процессоров, которые сейчас усиленно продвигаются на рынке железа.
Для начала хочу обратить внимание, что активно рекламировавшаяся в свое время технология HyperThreading фактически умерла - Intel больше не будет ее использовать в новых процессорах. Ссылок не даю, об этом не пишет только ленивый "железный" сайт. Соответственно, не могу не сопроводить это фразой - "я же говорил!": статью о вреде HyperThreading я написал больше года назад, однако маркетинговый посыл Intel был настолько силен, что до сих пор много людей уверены, что это замечательная технология.
Двухъядерные процессоры - это шаг вперед, который первой совершила AMD. Я предпочитаю AMD Интелу, поэтому попробую оценить преимущества двухъядерных процессоров именно на продукции этой фирмы. Для Intel, как показывают тесты, ситуация примерно похожая.
Итак, задача - понять, даст-ли что-нибудь мне приобретение двухъядерного процессора по сравнению с однопроцессорным. Во времена, когда ничего такого не было, и для серверов выбирали двух- или четырех-процессорные системы, результат был прост и понятен - в среднем увеличение производительности сервера в 1.7 раз.
А вот с двухъядерными - не так все просто и понятно. Допустим - процессор AMD 64 X2 3800+ - это два AMD 64 3800+ внутри одного, или нет?
Оказалось, что нет - как по тактовой частоте, так и по производительности.
У этих двух процессоров одинаковый размер кэша, но у одноядерного тактовая частота 2.4 мегагерца против 2-х мегагерц у двухъядерного.
Не буду мучить вас выкладками сравнений, тем более что мне физически нечего сравнивать. Я поступил просто - взял цифры из обзора, и провел дополнительные вычисления, базирующиеся на готовых цифрах производительности.
Если будете смотреть обзор, то не смотрите на цифры по "разогнанным процессорам". Если не нравится сам сайт, обратитесь к аналогичным статьям на ixbt.com или другом "железном" сайте.
Результат исследования, при сравнении одноядерных и двухъядерных процессоров с одинаковым "индексом" (как упомянутые выше):
Также, учитывая то, что я регулярно запускаю определенные тестовые процессы, во время работы которых систему лучше не трогать, дабы не искажать результат даже на "двухпроцессорной" машине, получается, что двухъядерный процессор мне просто противопоказан (т.к. работает в этом случае медленнее).
В этой заметке я хочу поделиться мыслями по поводу "двухъядерных" процессоров, которые сейчас усиленно продвигаются на рынке железа.
Для начала хочу обратить внимание, что активно рекламировавшаяся в свое время технология HyperThreading фактически умерла - Intel больше не будет ее использовать в новых процессорах. Ссылок не даю, об этом не пишет только ленивый "железный" сайт. Соответственно, не могу не сопроводить это фразой - "я же говорил!": статью о вреде HyperThreading я написал больше года назад, однако маркетинговый посыл Intel был настолько силен, что до сих пор много людей уверены, что это замечательная технология.
Двухъядерные процессоры - это шаг вперед, который первой совершила AMD. Я предпочитаю AMD Интелу, поэтому попробую оценить преимущества двухъядерных процессоров именно на продукции этой фирмы. Для Intel, как показывают тесты, ситуация примерно похожая.
Итак, задача - понять, даст-ли что-нибудь мне приобретение двухъядерного процессора по сравнению с однопроцессорным. Во времена, когда ничего такого не было, и для серверов выбирали двух- или четырех-процессорные системы, результат был прост и понятен - в среднем увеличение производительности сервера в 1.7 раз.
А вот с двухъядерными - не так все просто и понятно. Допустим - процессор AMD 64 X2 3800+ - это два AMD 64 3800+ внутри одного, или нет?
Оказалось, что нет - как по тактовой частоте, так и по производительности.
У этих двух процессоров одинаковый размер кэша, но у одноядерного тактовая частота 2.4 мегагерца против 2-х мегагерц у двухъядерного.
Не буду мучить вас выкладками сравнений, тем более что мне физически нечего сравнивать. Я поступил просто - взял цифры из обзора, и провел дополнительные вычисления, базирующиеся на готовых цифрах производительности.
Если будете смотреть обзор, то не смотрите на цифры по "разогнанным процессорам". Если не нравится сам сайт, обратитесь к аналогичным статьям на ixbt.com или другом "железном" сайте.
Результат исследования, при сравнении одноядерных и двухъядерных процессоров с одинаковым "индексом" (как упомянутые выше):
- одноядерный быстрее двухъядерного на обычных задачах, примерно на 15-25%.
- двухъядерный быстрее одноядерного на multithread-приложениях, примерно на 20-30%
- повышенную производительность (до 50%) на двухъядерном процессоре показали только редкие, специфические (вычислительные) приложения.
- операционная система на двухъядерном процессоре работает более "стабильно", в смысле общей загрузки. Причины этого тоже понятны.
Также, учитывая то, что я регулярно запускаю определенные тестовые процессы, во время работы которых систему лучше не трогать, дабы не искажать результат даже на "двухпроцессорной" машине, получается, что двухъядерный процессор мне просто противопоказан (т.к. работает в этом случае медленнее).
5.4.06
Жертвы тиража
За последние несколько лет в России и СНГ увеличилось количество программистов, использующих Delphi. При этом резко пострадало качество - достаточно посмотреть на частые вопросы, которые задаются на форумах (студенты не в счет). Также, как результат, резко упала зарплата по вакансии "программист, Delphi", в некоторых местах при приеме на работу даже собеседование стало чисто формальным. Возможно, эта тенденция справедлива и для других языков программирования, но по ним я не располагаю подобными сведениями.
Можно было бы подумать, что заголовок статьи относится к тем, кто как раз имеет хорошую квалификацию в этом предмете, и в результате вышеизложенного пострадал финансово. Но нет. Речь пойдет о тиражируемом ПО, разрабатывают которое как раз люди с недостаточной квалификацией.
К нам в техническую поддержку все чаще обращаются пользователи тиражируемых систем, построенных с использованием СУБД InterBase и Firebird, с жалобами на плохую производительность. Объемы баз данных в этих случаях являются весьма средними, что не дает повода для сомнений в производительности самих СУБД или аппаратных средств. Вы можете посмотреть на статистику по размерам БД в системах на IB/FB за 2003-2005 год, в презентации, которую я "озвучивал" на семинаре Корпоративные базы данных 2005 - "большие" базы данных в основном существуют в организациях, которые сами для себя разрабатывают ПО.
При помощи инструмента, который мы разработали примерно год назад, стало возможным оценивать производительность систем на IB/FB со стороны базы данных. То есть, посмотреть, что вытворяют приложения над БД, и хорошо ли они это делают. Применяя этот инструмент к тем самым тиражируемым системам, оказывается, что ситуация весьма печальна.
Одновременно, грустные мысли овладевают и при случайном ознакомлении со структурой таких БД - таблицами, процедурами и т.п.
То есть, получается следующая картина. У разработчиков "своих" систем проблем практически нет - если они и возникают, то достаточно быстро решаются через техподдержку, форумы и т.п. А в отношении тиражируемых систем
И, после начала продаж, тиражируемая система редко когда модифицируется. Бывают случаи, что одно и то же решение продается в неизменном виде несколько лет (исключим высококачественные системы, до сих пор функционирующие, к примеру на InterBase 4.1/4.2).
Косвенным результатом всего этого безобразия является прямо-таки профанация качества серверов InterBase и Firebird. И возможных решений этой ситуации я пока не вижу.
Изредка, правда, проскакивают идеи о введении некоего вида "сертификации" на звание программиста по тому или иному языку программирования. Может быть, и правда - покупателям стоит вначале знакомиться с уровнем квалификации разработчиков приобретаемой системы? Конечно, гарантий сертификация не дает, но может быть хотя бы такие действия заставят работодателей пытаться повысить квалификацию имеющихся или принимаемых на работу сотрудников?
p.s. я не называю имен, но боюсь, что если ситуация не изменится, придется по просьбе покупателей публиковать "черные списки". Это не угроза, но нельзя же так порочить доброе имя инструментов разработки и СУБД, правда?
Можно было бы подумать, что заголовок статьи относится к тем, кто как раз имеет хорошую квалификацию в этом предмете, и в результате вышеизложенного пострадал финансово. Но нет. Речь пойдет о тиражируемом ПО, разрабатывают которое как раз люди с недостаточной квалификацией.
К нам в техническую поддержку все чаще обращаются пользователи тиражируемых систем, построенных с использованием СУБД InterBase и Firebird, с жалобами на плохую производительность. Объемы баз данных в этих случаях являются весьма средними, что не дает повода для сомнений в производительности самих СУБД или аппаратных средств. Вы можете посмотреть на статистику по размерам БД в системах на IB/FB за 2003-2005 год, в презентации, которую я "озвучивал" на семинаре Корпоративные базы данных 2005 - "большие" базы данных в основном существуют в организациях, которые сами для себя разрабатывают ПО.
При помощи инструмента, который мы разработали примерно год назад, стало возможным оценивать производительность систем на IB/FB со стороны базы данных. То есть, посмотреть, что вытворяют приложения над БД, и хорошо ли они это делают. Применяя этот инструмент к тем самым тиражируемым системам, оказывается, что ситуация весьма печальна.
Одновременно, грустные мысли овладевают и при случайном ознакомлении со структурой таких БД - таблицами, процедурами и т.п.
То есть, получается следующая картина. У разработчиков "своих" систем проблем практически нет - если они и возникают, то достаточно быстро решаются через техподдержку, форумы и т.п. А в отношении тиражируемых систем
- с проблемами к нам обращаются покупатели, а не разработчики
- разработчики зачастую игнорируют проблемы с производительностью, возникающие у покупателей
- разработчиков таких систем не видно на форумах, не обращаются они и в техподдержку
- только 5-7% разработчиков, прошедших у нас обучение, занимаются тиражируемыми решениями (остальные разрабатывают "свои" системы)
И, после начала продаж, тиражируемая система редко когда модифицируется. Бывают случаи, что одно и то же решение продается в неизменном виде несколько лет (исключим высококачественные системы, до сих пор функционирующие, к примеру на InterBase 4.1/4.2).
Косвенным результатом всего этого безобразия является прямо-таки профанация качества серверов InterBase и Firebird. И возможных решений этой ситуации я пока не вижу.
Изредка, правда, проскакивают идеи о введении некоего вида "сертификации" на звание программиста по тому или иному языку программирования. Может быть, и правда - покупателям стоит вначале знакомиться с уровнем квалификации разработчиков приобретаемой системы? Конечно, гарантий сертификация не дает, но может быть хотя бы такие действия заставят работодателей пытаться повысить квалификацию имеющихся или принимаемых на работу сотрудников?
p.s. я не называю имен, но боюсь, что если ситуация не изменится, придется по просьбе покупателей публиковать "черные списки". Это не угроза, но нельзя же так порочить доброе имя инструментов разработки и СУБД, правда?
Подписаться на:
Сообщения (Atom)
