Кэш памяти сервер Ubuntu 9.10 x86 не работает как ожидалось

Эта команда покажет Вам всем файлы, к которым получили доступ (чтение), последнее 5 минут:

find / -amin -5

Если Вы хотите знать, какие файлы были изменены (пишут), используют -mmin опция вместо -amin.

0
задан 8 March 2010 в 16:43
3 ответа

2x 8x 500 МБ являются больше, чем Ваша машина на 4 ГБ когда-либо собирается содержать в кэше, таким образом, маловероятно, что любой из двух ПК добирается очень от кэша (т.е. все чтение файла приводит к доступу к диску).

Чтение двух файлов одновременно будет медленнее, чем чтение того, поскольку верхние части дисков должны будут зеркально отразить от файла до файла - эффект, это имеет на наблюдаемой производительности, может быть довольно значительным, если у Вас нет твердотельных дисков, где эффект минимизирован из-за почти нуля (относительно основанных на вращающем диске дисков) задержка произвольного доступа.

2x 2 ГБ все еще будут больше, чем Ваша машина может содержать в кэше в любой момент времени, так также не собирается полностью кэшироваться. Но большой блок его может быть, поэтому если машина 2 начнет читать то вскоре после машины 1 это будет блоки, кэшируемые во время машины 1 операции чтения. С 100 Мбит сетевая машина 2, вероятно, будет тем же расстоянием позади машины 1 в каждом файле во время целой операции. С 1Gbit сети дисков могут быть узким местом, в этом случае, машина 2 скоро нагонит, и эти два чередуются, между который причины физическое чтение и который получает кэшируемую копию блоков вместо этого.

Я подозреваю поэтому, что Вы видите активность диска в первом случае (ценность на 4 ГБ чтений), но будет мало посредством главных перемещений, таким образом, Вы на самом деле не услышите действие (если Вы прислушаетесь к нажатию дисков измерить это), и при этом некоторые не возглавят перемещения быть достаточно для создания, Вы заметили различие в скорости. К тому времени, когда первая машина добирается в конец передачи, запуск файлов будет продвинут из кэша, но вторые и последующие машины или еще не запустились или считали кроме того точку уже так или иначе.

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

1
ответ дан 4 December 2019 в 23:09

Я думаю, что замедление Вашего наблюдения происходит главным образом из-за сетевого уровня. Фантомная многоадресная передача использования настолько 10 компьютеров обработки изображений с 1 изображением совпадает с обработкой изображений 1 компьютера. Но если Вы широковещательно передаете 2 изображения сразу затем, оба широковещательных сообщения конкурируют за сетевую пропускную способность.

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

0
ответ дан 4 December 2019 в 23:09

David записал:

2x 8x 500 МБ больше, чем Ваша машина на 4 ГБ

В нашем тесте с HP7700 и HP7800 у нас есть 2 изображения, которые разделены на (приблизительно 8) сегменты. На изображение только один сегмент потребностей на 500 МБ, которые будут загружены в кэше simultaneaously.

Так 2x 500 1 ГБ. Когда определенный сегмент полностью загружается в клиент, следующий сегмент потребностей на 500 МБ, которые будут загружены. Но у нас было много активности диска. (С 1 большим сегментом 2 ГБ и только загружающийся к HP7800 диски сервера ничего не делают...),

3dinfluence: мы не используем многоадресную передачу, каждый клиент загружается непосредственно с сервера.

0
ответ дан 4 December 2019 в 23:09

Теги

Похожие вопросы