forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Раздел полезных советов: Почему на нагруженных серверах лучше использовать SCSI диски, а не IDE., auto_tips (?), 23-Май-04, (0) [смотреть все]

полностью согласен, но почему не говорите о минусах SCSI цена например , Anonymous (?), 08:31 , 23-Май-04, (1) //

а почему не говорят о альтернативе SATA , Single mode (?), 09:31 , 31-Май-04, (2)

А это никто не может, ибо это невозможно в принципе - каждое устройство занимает, Дмитрий Ю. Карпов (?), 18:16 , 31-Май-04, (3) //

По вашим словам IDE прям как soft-modem какой-то CPU тоже докупайте, который бу, uldus (ok), 20:52 , 31-Май-04, (4) //

Для начала давайте сравним объём кэша в операционке и в диске Т к обычно объём, Дмитрий Ю. Карпов (?), 14:29 , 01-Июн-04, (6) //

Зависимость вероятности попадания данных из кэша от объема кэша и параметров дис, uldus (ok), 14:52 , 01-Июн-04, (7)

uldus Расскажите, pls, как вычисляется этот оптимум Лично мне сей алгоритм неве, Дмитрий Ю. Карпов (?), 20:27 , 02-Июн-04, (10)
Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Se, Константин (??), 10:01 , 11-Ноя-04, (14)

Если IDE винт на контроллере один, то по скорости он скизи почти не уступает Пр, AdVv (??), 12:17 , 01-Июн-04, (5) //

По скорости работы IDE подошли к SCSI160 r w 55Mb s ээ, 98 год помоему первый, bass (??), 17:33 , 01-Июн-04, (8)

В системе с одним винчестером на канал разницы в производительности можно не зам, Тма (?), 17:01 , 02-Июн-04, (9)
а google на чем вертится не на ide ли винтах вот только контроллеры у них не о, shadowcaster (?), 22:53 , 13-Июн-04, (11) //

да, вертится гугль на иде-винтах, только не нужно стравнивать самосборные сервак, Sergey (??), 16:47 , 28-Июн-05, (15)

а почему не расмотреть fibre chanell на серверах помоему ни в чём не уступают ск, Дима Авдеев (?), 23:26 , 22-Июн-04, (12)
Если Вы имеете в виду FC-AL, то, поверьте, они ОЩУТИМО уступают SCSI в производи, rippy (ok), 01:22 , 27-Июн-04, (13)

Сообщения [Сортировка по времени | RSS]

3. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от Дмитрий Ю. Карпов (?), 31-Май-04, 18:16

> Два подключенных к одному каналу контроллера IDE накопителя,
> не могут  одновременно передавать данные по шине.
А это никто не может, ибо это невозможно в принципе - каждое устройство занимает шину целиком. К тому же это малоактуально.
> При  использовании SCSI, допускается перекрытие запросов
> (организуется очередь команд), ответы при этом  будут получены
> распараллеленно (асинхронная передача), при этом устройство
> заведомо зная подробности  по командам находящимся в очереди,
> производит оптимизацию самостоятельно - минимизируя движение головок.
Эту оптимизацию должна производить операционная система. А на разницу в цене IDE и SCSI я докуплю памяти, где эта оптимизация и будет производиться.

Ответить | Правка | Наверх | Cообщить модератору

4. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от uldus (ok), 31-Май-04, 20:52

>Эту оптимизацию должна производить операционная система. А на разницу в цене IDE
>и SCSI я докуплю памяти, где эта оптимизация и будет производиться.
По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте, который будет дисковые операции планировать и расквантовывать ? :-)

Ответить | Правка | Наверх | Cообщить модератору

6. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от Дмитрий Ю. Карпов (?), 01-Июн-04, 14:29

> По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте,
> который будет дисковые операции планировать и расквантовывать ? :-)
Для начала давайте сравним объём кэша в операционке и в диске. Т.к. обычно объём оперативки >> кэша на брюхе у диска, то операционка в любом сучае должна оптимизировать свои запросы к диску. А оптимизировать на малой памяти то, что уже было оптимизировано на большой - это то же самое, что паковать плохим архиватором то, что уже упаковано хорошим.

Ответить | Правка | Наверх | Cообщить модератору

7. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от uldus (ok), 01-Июн-04, 14:52

>Для начала давайте сравним объём кэша в операционке и в диске.
Зависимость вероятности попадания данных из кэша от объема кэша и параметров диска не линейная, есть оптимум, который и используют. Кэшировать то что уже считано и то что может быть будет считано разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.
Другой контраргумент: ОС точно не знает где сейчас висит головка, а электроника диска знает.

Ответить | Правка | Наверх | Cообщить модератору

10. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от Дмитрий Ю. Карпов (?), 02-Июн-04, 20:27

uldus:
> Зависимость вероятности попадания данных из кэша от объема кэша
> и параметров диска не линейная, есть оптимум, который и используют.
Расскажите, pls, как вычисляется этот оптимум. Лично мне сей алгоритм неведом.
> Кэшировать то что уже считано и то что может быть будет считано
> разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.
Вы думаете, что диск лучше знает, что операционка будет читать в будущем? :)
> Другой контраргумент: ОС точно не знает где сейчас висит головка,
> а электроника диска знает.
У диска есть два параметра, определяющих время выполнения запроса: это начальная задержка T0 и скорость считывания/записи V (т.е. время обработки запроса объёмом N байт = T0 + N/V). Чтобы второе слагаемое стало больше первого, с диском надо общаться порциями в несколько сотен килобайт, что, IMHO, бывает нечасто.
V - это константа, на ней никакими манипуляциями ничего не выиграешь.
T0 состоит из двух слагаемых: время на перемещение головки и время на ожидание прихода под головку нужного сектора; причём второе существенно больше первого (паспортное время задержки обычно почти совпадает с полуоборотом диска).
Операционная система видит диск как линейно пронумерованный набор секторов и знает, что чем больше различаются номера секторов, тем дальше надо двигать головку. Поэтому первое слагаемое, составляющее T0, операционная система оптимизирует достаточно хорошо.
При упорядочении обращений к диску по номерам секторов (а хорошая операционка, особенно многозадачная с "умным" планированим процессов именно так и делает) минимизируется и ожидание прихода сектора под головку (для случаев обращения в один цилиндр). Так что диску тут просто нечего упорядочивать.
И наконец, последний гвоздь в крышку гроба:
Если в системе выполняются транзакции (надеюсь, никому не надо объяснять, что это такое), к числу которых относятся файловые системы NTFS (W'NT) и UFS+SoftUpdates (FreeBSD), то очерёдность записи на диск определяется программами и НЕ ДОЛЖНА МЕНЯТЬСЯ ДИСКОМ. Так что диску ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ запись на него; а при достаточной памяти (купленной на разницу в стоимости IDE и SCSI) чтение хорошо кэшируется операционкой в памяти, установленной на мат.плате.

bass:
> По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что на смену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.
О какой скорости мы говорим - о скорости электрического интерфейса или о скорости работы механики диска? Тормозом является именно механика (именно она обеспечивает T0), а она от интерфейса (IDE или SCSI) не зависит.
Конечно, в более догогие SCSI-диски ставят более качественную и быструю механику. Но если взять дорогой IDE-диск, то он будет работать так же, как SCSI, при меньшей чем у SCSI цене. IMHO.
PS: А что у вас делают в промышленных системах процессоры Xeon, которые сами греются ка муфельная печка?

Ответить | Правка | Наверх | Cообщить модератору

14. "Раздел полезных советов: Почему на нагруженных серверах лучш..." +/–

Сообщение от Константин (??), 11-Ноя-04, 10:01

>Другой контраргумент: ОС точно не знает где сейчас висит головка, а >электроника диска знает.
Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Seek - один в один оптимизация на уровне ОС. НО !!!!! работает только со СКАЗЯМИ !, т.к. у других ничего о _физическом_ положении головок сказать нельзя. Головки при этом перемещаются ЛИНЕЙНО по ВСЕЙ поверхности диска - что хорошо сказывается на ресурсе.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

3. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
Сообщение от Дмитрий Ю. Карпов (?), 31-Май-04, 18:16
> Два подключенных к одному каналу контроллера IDE накопителя, > не могут одновременно передавать данные по шине. А это никто не может, ибо это невозможно в принципе - каждое устройство занимает шину целиком. К тому же это малоактуально. > При использовании SCSI, допускается перекрытие запросов > (организуется очередь команд), ответы при этом будут получены > распараллеленно (асинхронная передача), при этом устройство > заведомо зная подробности по командам находящимся в очереди, > производит оптимизацию самостоятельно - минимизируя движение головок. Эту оптимизацию должна производить операционная система. А на разницу в цене IDE и SCSI я докуплю памяти, где эта оптимизация и будет производиться.
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
	Сообщение от uldus (ok), 31-Май-04, 20:52
	>Эту оптимизацию должна производить операционная система. А на разницу в цене IDE >и SCSI я докуплю памяти, где эта оптимизация и будет производиться. По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте, который будет дисковые операции планировать и расквантовывать ? :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
	Сообщение от Дмитрий Ю. Карпов (?), 01-Июн-04, 14:29
	> По вашим словам IDE прям как soft-modem какой-то. CPU тоже докупайте, > который будет дисковые операции планировать и расквантовывать ? :-) Для начала давайте сравним объём кэша в операционке и в диске. Т.к. обычно объём оперативки >> кэша на брюхе у диска, то операционка в любом сучае должна оптимизировать свои запросы к диску. А оптимизировать на малой памяти то, что уже было оптимизировано на большой - это то же самое, что паковать плохим архиватором то, что уже упаковано хорошим.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
	Сообщение от uldus (ok), 01-Июн-04, 14:52
	>Для начала давайте сравним объём кэша в операционке и в диске. Зависимость вероятности попадания данных из кэша от объема кэша и параметров диска не линейная, есть оптимум, который и используют. Кэшировать то что уже считано и то что может быть будет считано разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором. Другой контраргумент: ОС точно не знает где сейчас висит головка, а электроника диска знает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
	Сообщение от Дмитрий Ю. Карпов (?), 02-Июн-04, 20:27
	uldus: > Зависимость вероятности попадания данных из кэша от объема кэша > и параметров диска не линейная, есть оптимум, который и используют. Расскажите, pls, как вычисляется этот оптимум. Лично мне сей алгоритм неведом. > Кэшировать то что уже считано и то что может быть будет считано > разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором. Вы думаете, что диск лучше знает, что операционка будет читать в будущем? :) > Другой контраргумент: ОС точно не знает где сейчас висит головка, > а электроника диска знает. У диска есть два параметра, определяющих время выполнения запроса: это начальная задержка T0 и скорость считывания/записи V (т.е. время обработки запроса объёмом N байт = T0 + N/V). Чтобы второе слагаемое стало больше первого, с диском надо общаться порциями в несколько сотен килобайт, что, IMHO, бывает нечасто. V - это константа, на ней никакими манипуляциями ничего не выиграешь. T0 состоит из двух слагаемых: время на перемещение головки и время на ожидание прихода под головку нужного сектора; причём второе существенно больше первого (паспортное время задержки обычно почти совпадает с полуоборотом диска). Операционная система видит диск как линейно пронумерованный набор секторов и знает, что чем больше различаются номера секторов, тем дальше надо двигать головку. Поэтому первое слагаемое, составляющее T0, операционная система оптимизирует достаточно хорошо. При упорядочении обращений к диску по номерам секторов (а хорошая операционка, особенно многозадачная с "умным" планированим процессов именно так и делает) минимизируется и ожидание прихода сектора под головку (для случаев обращения в один цилиндр). Так что диску тут просто нечего упорядочивать. И наконец, последний гвоздь в крышку гроба: Если в системе выполняются транзакции (надеюсь, никому не надо объяснять, что это такое), к числу которых относятся файловые системы NTFS (W'NT) и UFS+SoftUpdates (FreeBSD), то очерёдность записи на диск определяется программами и НЕ ДОЛЖНА МЕНЯТЬСЯ ДИСКОМ. Так что диску ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ запись на него; а при достаточной памяти (купленной на разницу в стоимости IDE и SCSI) чтение хорошо кэшируется операционкой в памяти, установленной на мат.плате. bass: > По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что на смену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем. О какой скорости мы говорим - о скорости электрического интерфейса или о скорости работы механики диска? Тормозом является именно механика (именно она обеспечивает T0), а она от интерфейса (IDE или SCSI) не зависит. Конечно, в более догогие SCSI-диски ставят более качественную и быструю механику. Но если взять дорогой IDE-диск, то он будет работать так же, как SCSI, при меньшей чем у SCSI цене. IMHO. PS: А что у вас делают в промышленных системах процессоры Xeon, которые сами греются ка муфельная печка?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Раздел полезных советов: Почему на нагруженных серверах лучш..."	+/–
	Сообщение от Константин (??), 11-Ноя-04, 10:01
	>Другой контраргумент: ОС точно не знает где сейчас висит головка, а >электроника диска знает. Не совсем так, вот например Novell имеет алгоритм кэширования записи Elevator Seek - один в один оптимизация на уровне ОС. НО !!!!! работает только со СКАЗЯМИ !, т.к. у других ничего о _физическом_ положении головок сказать нельзя. Головки при этом перемещаются ЛИНЕЙНО по ВСЕЙ поверхности диска - что хорошо сказывается на ресурсе.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору