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


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

В этой теме 16 ответов, 8 участников, последнее обновление  yota 5 года/лет, 3 мес. назад.

  • Автор
    Сообщения
  • #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
    Участник

    ..

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