|
ru.networks
- RU.NETWORKS ------------------------------------------------------------------
From : Artem I. Ivanov 2:5020/400 23 Jan 2001 20:47:57
To : All
Subject : Re: Какое оборудование выбрать?
--------------------------------------------------------------------------------
Привет Всем
> Теперь пункт два: ты в состоянии понять что 90 процентов
> данных идут не с диска, а из памяти?
> Для примера - попаданий в кэш на NW4.11 95% , LRU около часа.
> ну и каким-же боком тут тормоза диска уперлись?
И чего ты, горячий парень Слав Матвеев, все время кричишь на меня. Всю
рыбу распугал :-)
И пример твой, по правде говоря, не удачней моего. Возьми, к примеру,
файл заведомо больший размера кэша раза в три и скачай его с сервера. Скорее
всего, ты обнаружишь, что твой процент попаданий в кэш не уменьшился
нисколько. Полагаю - эффект упреждающего чтения - если твой файл-сервер
читает сразу по 64 К, то данные для 5 кадров из 6-ти будут заранее в кэше.
Однако, файл-то все-равно пришлось весь с диска прочесть.
Грубо говоря, все прочитанное с диска и на него записаное, проходит через
кэш, но это не означает, что все, что ты читаешь или пишешь на сервер будет
тусоваться в кэше весь рабочий день :-(
> Пункт три: ты когда-нибудь оракл пытался оптимизировать?
> А хотя бы руководство про это читал? на тему того как там
> рекомендуется разносить данные. по нескольким томам.
> А если ты на десктопной системе пытаешься оракл запустить,
> то не фига на зеркало... на сеть пенять.
Опять советы почитать "иже еси на небеси" три раза на ночь и постоять на
горохе. Hадеюсь, мы с тобой оба понимаем, что HАСТОЯЩАЯ оптимизация oracle
происходит в иной области, чем грубые материи дискового и сетевого
ввода-вывода.
> AI> очень-то верю :-) Novell - другое дело, да там ведь и файловое
> AI> пространство десятками ГБ меряется.
> И что, там все десятки гигобайт в оперативном доступе?
> Посмотри на параметры, выдаваемые монитором, потом почитай
> в документации какие эти цифры должны быть, и почитай какими
> средствами этих цифр достигнуть. Может тогда поймешь,
> что тормоза кроются в банальном несоответствии техники выполняемым
> задачам.
Да в среднем, полагаю, так и обстоит дело - именно в оперативном
доступе. Сидят пользователи и бегают по всем томам вдоль и поперек. И никак
от них не отделаюсь :-)
> AI> большинства организаций, полагаю, - подключение файл-сервера через
> AI> две 100 МБ карты не приведет к увеличению скорости его работы. Или вы
> AI> по-прежнему со мною не согласны ? Просто приведите кто-нибудь
реальный
> AI> пример ... Мне и самому интересно.
> Скажи мне, почему интернет-сервера ставят на быстрые каналы?
> ведь клиенты в большинстве своем имеют диал-ап и один
> фиг быстрее 4-5кб/с не укачают...
Ты, вот, так-таки и не прочел вопроса-то, похоже.
А хотел-то я сказать вот-что. Если вчера человеку хватало 10 Мбит на
всю сеть, а сегодня он собрался свич 100 Мб поставить, то не стоит сразу
бросаться транки прокладывать и 400 МБ линки к серверу ладить, хотя бы из
простого соображения, что количество информации, которое заданное число
людей может обработать - более или менее постоянное, и скорость эта, в
основном, определяется состоянием рабочих мест, а не сервера. И если у меня
пользователь работает в пяти программах одновременно, то вряд ли он сможет
работать в десяти при замене 10 МБит на 100. Стоит сначала оценить свой
траффик, а многие об этом не задумываются даже. Что против этого
возразить-то можно ?
А что можно загрузить 100 МБит - охотно верю, только какое это имеет
отношение к среднестатистической "провинциальной" Московской сети, в
которой, рискну предположить, и выделенного сервера-то нет, не то что свича.
Артем Иванов
--
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Talk.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
