x86 таки наступает на пятки

Главная Форумы Курилка Обо всём x86 таки наступает на пятки

Просмотр 16 веток ответов
  • Автор
    Сообщения
    • #16808
      uxTuaHgp
      Участник
    • #16809
      andrewk
      Участник

      кому? 🙂

      Strong sales of x86 servers does not mean RISC and mainframe systems are heading to oblivion. IBM in the quarter topped the server market in revenue, as sales of its System z mainframe rose 29% year over year, according to IDC.

    • #16810
      Sever
      Участник

      Wiindows всегда останется Windows независимо от числа ядер в сервере.

    • #16815
      Andriy
      Участник

      [url url=http://www.informationweek.com/hardware/windows-servers/sgi-introduces-256-core-windows-server/229400381]SGI Introduces 256-Core Windows Server[/url]

      ну т. е. число ядер это прям таки вот раз – и догнали Power?

    • #16816
      uxTuaHgp
      Участник

      Вот именно и по производительности ядра вроде как Xeon бьет Power7

    • #16817
      Sever
      Участник

      Вспомнил.
      несколько лет назад проходила информация, что наш Гидрометцентр закупил у SGI суперкомпьютер для обеспечения своей жизнедеятельности. Решил поинтересоваться, как же новые технологии работают на благо нашего гидромета…
      Как известно, в интернете сегодня можно найти много чего интересного.
      Вот интересный документ:
      http://method.hydromet.ru/techno/3d_var.html

      В период с 16 апреля по 4 сентября 2011 г. были получены и обработаны данные по 475 срокам наблюдений (из общего количества 568 сроков – 142 дня). При расчёте полей ОА за указанный период было выявлено 33 сбоя, причем некоторые сбои приводили к отказам расчёта анализов за несколько последовательных сроков. Были выявлены следующие причины сбоев:
      – сбои в работе ЭВМ Altix-4700 – 12 случаев или 36% от общего числа сбоев;
      – сбои в работе 8-го вычислительного узла – 3 случая или 9 %;
      – отсутствие полей первого приближения в БД NCMN – 7 случаев или 21 %;
      – сбои в работе базы данных анализов (БД F385) – 1 случай или 3 %;
      – сбои в новой схеме анализа – 3 случая или 9 %;
      – сбои по неустановленным причинам – 7 случаев или 21
      %.

    • #16824
      uxTuaHgp
      Участник

      Какая-то лажа.
      Не верю. Свои косяки замазывали таким отчетом.

    • #16825
      andrewk
      Участник

      вопросы веры переубеждению не поддаются. поэтому каждый продолжит верить в своё 🙂

    • #16826
      uxTuaHgp
      Участник

      под сбоем сервера может подразумеваться любое зависание, а к зависанию могут привести всевозможные ошибки разработчиков, тем более если разработка ведется на Си, то получить всевозможные утечки памяти элементарно просто.
      Система в результате может уйти своп например и перестать отвечать.
      Сбой?
      Сбой.
      Да мало ли чего можно напрограммаздить такого, что уронит сервер.

    • #16827

      > и по производительности ядра вроде как Xeon бьет Power7

      На каких задачах? Все таки для баз данных Xeon слабее P7 из-за SMT4 у последнего.

    • #16829
      roman
      Участник

      > и по производительности ядра вроде как Xeon бьет Power7

      На каких задачах? Все таки для баз данных Xeon слабее P7 из-за SMT4 у последнего.

      А чем SMT4 так сильно помогает для баз данных?

    • #16830

      Больше сессий тянет в параллели.

    • #16831
      andrewk
      Участник

      это только если ваши разработчики не забыли о наличии нескольких процессоров… а если забыли и запустили одну большую процедуру, которая не параллелизуется и как следствие – работает только на одном процессоре, то от SMT4 только вред.

    • #16832

      Это да, но на деле я таких баз данных не видел никогда. Все с чем я сталкивался так или иначе на том конце имело несколько тысяч человек или машин, которые чего-то от этой базы хотят, соотвественно параллелизация достигается естественно.

      Кроме того, современные движки баз достаточно умны. Тот же оракл (в ентерпрайз версии) умеет обычный select распараллеливать. Особенно у него хорошо получается если в селекте десяток подзапросов или применяется он к партицированной таблице.

      Поэтому на практике я не сталкивался с проблемой “плохой программист шпарит в один поток”.

    • #16833
      andrewk
      Участник

      а я видел. процедура называлась End Of Day, была от разных разработчиков, на разных платформах и в разных банках, а проблема была у всех одинаковая…

    • #16837
      barmaley
      Участник

      Кроме того, современные движки баз достаточно умны. Тот же оракл (в ентерпрайз версии) умеет обычный select распараллеливать. Особенно у него хорошо получается если в селекте десяток подзапросов или применяется он к партицированной таблице.

      just 2 cent’s :

      Пару месяцев назад проводил небольшое тестирование новой DB2 10.1 на предмет оценки производительности селектов с фуллсканом по компрессным таблицам в несколько паралдельных потоков. Удалось собрать две тестовые системы для сравнения :

      1. Dedicated LPAR (EC=8, VP=8) AIX 6.1 TL6 SP5 на POWER730 (3.7GHz) + NPIV+ jfs2 на RAID5 (7+1)
      2. Виртуалка SLES11 SP1 (8 VCPU) под vSphere 4.1 на x3650M3 (Xeon x5690 3.4Ghz) + EXT3/VMFS на RAID5 (7+1)

      На 8-ми потоках DB2/SLES показывала результат на 10-12% выше, чем DB2/AIX.
      При включении SMT4 и увеличении числа потоков DB2 до 32-х разница сократилась до 5-7%, но все равно меньше, чем результат DB2/SLES.
      Обе системы (и SLES и AIX) специально не тюнились. Возможно, если подкрутить I/O настройки в AIX (знать бы, что конкретно, а то много всего), то будет лучше.

    • #16838
      yota
      Участник

      ..

Просмотр 16 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.