|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Andrew Lesnichenko 2:5020/400 06 Sep 2002 20:36:25
To : Tengiz Kharatishvili
Subject : Re: Hа: ответственная БД
--------------------------------------------------------------------------------
s.ru> <od4nmu8ir7bcri6ccrq299vmmak4qp5q1g@4ax.com> <3D6CE648.4010103@mts.ru>
s.ru> <b72vmuka9uohkjsamqme20ga199fgejd9d@4ax.com>
s.ru> <ako6ag$qk9$1@slim.sovintel.ru>
s.ru> <e3o1nu0jabnu2oocp1jf236crnbev7cc3c@4ax.com>
s.ru> <al1jel$esk$1@slim.sovintel.ru>
s.ru> <aqh9nu8h30htuoip816o81boqsnk6314fs@4ax.com>
s.ru> <al2ji6$uhj$1@slim.sovintel.ru> <al344b$lsa$3@news.kot.poltava.ua>
s.ru> <al4l8g$uhd$1@slim.sovintel.ru> <al9khr$2fe2$1@ddt.demos.su>
s.ru> <al9o0f$e7v$1@slim.sovintel.ru> <al9p83$a64$1@ddt.demos.su>
s.ru> <al9ptr$es5$1@slim.sovintel.ru> <alajhb$1m9b$1@ddt.demos.su>
From: Andrew Lesnichenko <les@mts.ru>
Tengiz Kharatishvili wrote:
>
> А если серьёзно - то в десятках сообщений здесь явно или неявно утверждалось
> примерно следующее: система на x86 не может хорошо масштабироваться, так как
> не только сам процессор не очень, не только шинный модуль у него не расчитан
> на эффективую мультипроцессорную работу, но также и системы, где он
> используется, сделаны без учёта требований масштабируемости - симметричные
> SMP на общей шине очень быстро упираются в органиченую пропускную
> способность такой конфигурации даже с самым лучшими процессорами с самыми
> большими кешами.
>
> Я привёл пример железки (информация о которой доступна - было бы только
> желание разобраться), где используется то, в том числе и на наличие чего в
> "правильных" системах и были явные ссылки или прозначные намёки - crossbar
> (который тот же SUN позаимствовал в мире мейнфреймов). Откуда следует, что
> об ограничении общей шины для x86 можно забыть.
Мы говорим в контексте баз данных, т.е. нам нужен доступ ко всей памяти
в сервере и ко всему дисковому пространству. Hи для кого не секрет, что
эффективнее всего иметь один CPU - он ни с кем не конкурирует. Следующая
стадия - SMP. Все CPU имеют доступ ко всему полю памяти и время доступа
одинаково для всех адресов. Производители СУБД научились разруливать
конкуренцию. Следующая стадия - NUMA. Когда все CPU имеют доступ ко
всему полю памяти, но к удаленным банкам, которых в системе подавляющее
большинство, время доступа выше, чем к локальным. Если не ошибаюсь, 1:3.
При этом СУБД можно не переделывать, но хотелось бы использовать
особенности NUMA, ибо без этого, коэфф. масштабируемости значительно
хуже, чем у SMP.
И что мы имеем на практике. Intel имеет не больше 8-ми CPU на общей
шине, тогда как Sun имеет 32. Есть разница ? Intel имеет 32 CPU на одном
хосте, тогда как Fujitsu имеет 128 (на коммутаторе). Есть разница ?
Будучи очень неплохим процессором в одиночестве, Intel, будучи собраным
в количестве 32-х штук, проиграл в 1,3 раза 24-ной тачке (у которой к
тому же процессорная частота в 1,5 раза меньше). Это потому, что там
была SMP или потому что коммутатор у Bull/IBM гораздо лучше, чем у UNISYS ?
> Кстати, по-моему, ни разу толком не прозвучало, что же такого неправильного
> в bus unit у современных x86. Хотя на самом деле там всё в порядке - имеется
> и широкое слово данных, и блочные передачи, и аппаратная когерентность
> кешей, и даже то, чего нет у других архитектур: гарантии соблюдения
> программного порядка записи в память.
Все хорошо, вот только собрать больше 8-ми штук вместе эффективно не
удается.
--
Andrew Lesnichenko
--- ifmail v.2.15dev5
* Origin: Mobile TeleSystems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
