fregimus: (Default)
[personal profile] fregimus
ЖЖ всю последнюю неделю работает очень медленно. Причина, как здесь говорится, в самой обычной перегрузке компьютерной системы. Во-первых, программная ошибка: данные лишний раз читаются с диска, хотя они уже находятся в памяти. Во-вторых, просто не достаточно пропускной способности машин, не рассчитали на рост нагрузки. Обещают начать ремонт в грядущий понедельник, а мы пока посмотрим на новую технологию постоянной памяти, которую применяет ЖЖ. Параметры ее впечатляющи (по ссылке объяснения в первом комментарии).

Самый современный диск в домашнем компьютере читает и записывает данные не быстрее 40 МБ/с. Скорость работы дорогих дисков для сервера выше, но не намного (не на порядок). Чтобы увеличить скорость обмена, данные раскладываются в массивы параллельно работающих дисков, так что при записи данные дробятся на несколько фрагментов, которые записываются на несколько дисков одновременно.

Однако, и эта технология имеет ограничения: можно увеличить скорость в несколько раз, но не более того, ведь дробить информацию на сотни дисков не практично. Резкое увеличение скорости доступа возможно, если вместо обычных крутящихся магнитных дисков подключать устройства, хранящие информацию в полупроводниковых микросхемах — FLASH (Такие «диски» называются SSD, буквально «твердотельные накопители»). Цена таких устройств на бит хранимой информации высока, а объем относительно мал, но намного выше и скорость доступа.

Однако, здесь начинается следующая проблема: контроллер записи/чтения диска — «посредник» между диском и оперативной памятью вычислительной машины — конструируется в расчете на обычный, относительно «медленный» диск. Обычные контроллеры не справляются с высокой скоростью SSD, просто не способны поставлять столько данных в секунду, сколько диск может записать. Получается, что контроллер делается узким местом, не позволяет использовать дорогие быстрые накопители на полную мощность.

Решение простое и изящное. Нужно просто поместить микросхемы FLASH на одну плату со специальным, сконструированным в расчете на них, контроллером. Такая плата вставляется прямо в шину компьютера, обеспечивая максимально быстрый обмен данными с накопителем. Насколько быстрый?



ЖЖ пользуется накопителями фирмы Fusion-io. Более медленный и объемистый вариант накопителя хранит 640 ГБ данных и обеспечивает доступ со скоростью 1 ГБ/с на запись и 1,5 ГБ на чтение. Быстрый вариант вдвое меньшей емкости 320 ГБ обеспечивает и чтение, и запись со скоростью 1,5 ГБ/с. В серверах ЖЖ ставятся по два накопителя, фактически работая с предельной скоростью внутренней шины компьютера — дальнейшее ускорение просто не имеет смысла.

Стоят оба устройства как простенький автомобиль — 13 тыс. долл. каждое. Это дороже дискового массива той же емкости и скорости, но, во-первых, занимает много меньше места, во-вторых, потребляет гораздо меньше энергии, и, в-третьих, надежнее.

К слову, энергопотребление не зря оказалось в списке критических достоинств технологии. Цена электроэнергии весьма чувствительна при эксплуатации больших вычислительных центров. Хорошо известно, что Google открывает свои центры обработки данных возле электростанций — там, где цена электроэнергии ниже!

(no subject)

2010-04-09 22:19 (UTC)
Posted by [identity profile] http://users.livejournal.com/_aristeo/
Но у SSD, насколько мне известно, существует предел количества операций чтения/записи, чего нет у отдельных винчестеров. Или не так?

(no subject)

2010-04-09 22:23 (UTC)
Posted by [identity profile] miollnyr.livejournal.com
+1
Это значит что и изнашиваются они в быстрее чем обычные HDD.

(no subject)

2010-04-09 22:36 (UTC)
Posted by [identity profile] fat-crocodile.livejournal.com
AFAIK, хитрый контроллер переименовывает сектора так, чтобы незаметно распределить нагрузку по всему диску. Иначе популярные файлы (своп, например) прожигали бы в диске дырку за месяц эксплуатации. А так ничего, держатся.

(no subject)

2010-04-10 00:21 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Только записи, не чтения.

Все ведь изнашивается. Не знаю, как решают проблему перезаписи. Кажется, недавно говорили о долговечности порядка 100 тыс. перезаписей для FLASH. Интересно прикинуть, сколько раз за время жизни диска обычно перезаписывается один сектор?

Наверное, зависит от режима работы с информацией. Для ЖЖ, где информация вводится однажды, а затем редко меняется — весьма подходящее применение.

(no subject)

2010-04-10 00:38 (UTC)
Posted by [identity profile] fat-crocodile.livejournal.com
> Интересно прикинуть, сколько раз за время жизни диска обычно перезаписывается один сектор?

Очень неравномерно.

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

Я потому и написал про перемещение секторов, конечно, имел ввиду при перезаписи, чтение не имеет такого деструктивного эффекта.

(no subject)

2010-04-10 00:45 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Наверное, для оценки имеет смысл говорить о среднем числе операций записи. Читал — не знаю, насколько это правда — что аппаратура SSD перенаправляет запись в разные секторы, чтобы выравнивать число операций записи на сектор. Дело давно было, не знаю, является ли это до сих пор проблемой.

Своп-файл: когда вы покупаете накопители по 13 грандов, рекомендуется увеличить RAM, чтобы свопинг происходил не так интенсивно — независимо от того, ограниченное ли время жизни накопителей.

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

(no subject)

2010-04-10 08:31 (UTC)
Posted by [identity profile] silpol.livejournal.com
не совсем - для ЖЖ больше подходит унос в архивный (более медленный но серьезно более дешевый) носитель того, что относительно долго не читалось: таким методом почти не увеличиваются расходы на полосу пропускания за пределы контура, но зато серьезно дешевеет носитель (а флэш пока еще не дешев)

(no subject)

2010-04-10 08:35 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Да, пожалуй. Не представляю, какую стратегию они используют.

(no subject)

2010-04-10 09:38 (UTC)
Posted by [identity profile] silpol.livejournal.com
я не знаю за ЖЖ, всегда лень было лезть в перловый код :)

(no subject)

2010-04-09 22:38 (UTC)
Posted by [identity profile] fat-crocodile.livejournal.com
> Цена электроэнергии весьма чувствительна при эксплуатации больших вычислительных центров.

Да, я когда-то с огромным удивлением узнал, что _основные_ расходы Яндекса -- это электричество.

Интересный пример перехода количества в качество, для обычного пользователя стоимость электроэнергии, потребляемой ПК пренебрежимо мала.

(no subject)

2010-04-10 00:24 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Зависит от пользователей. У некоторых (например, данного) серверы стоят в гардеробе и считают почти что непрерывно на все 100% всеми 4 процессорами — тут уже чувствительно, где-то 120 ватт каждый.

(no subject)

2010-04-10 00:48 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Дурацкие NP-полные задачи, возникающие в машинном обучении. Не знаю пока, что считаю. Дальше видно будет.

(no subject)

2010-04-09 23:13 (UTC)
Posted by [identity profile] evil-gryphon.livejournal.com
Откройте страничку
http://fregimus.livejournal.com/94764.html
и сохраните её в разных форматах
форматах txt (только текст) - 8723 байт
фотография (изображение контроллера) - 65153 байт
htm (текст со средствами разметки и встроенным кодом - суповской рекламой и прочим мусором) - 47200 байт
mht (всё вместе одним файлом) - 658142 байта.

Это означает что более 90% передаваемой информации является мусором и если оптимизировать ЖЖ, убрать рекламу и всякое подобное ггг то нагрузку на сервер (и его подсистему памяти) можно уменьшить в 10 раз.

(no subject)

2010-04-10 00:17 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Думаю, что на сервере хранятся все-таки не странички одним чохом — скорее текст.

(no subject)

2010-04-10 00:46 (UTC)
Posted by [identity profile] fat-crocodile.livejournal.com
И скорее всего -- пожатый.
Во всяком случае Contenet-encoding он отдаёт gzip.

(no subject)

2010-04-10 00:50 (UTC)
Posted by [identity profile] fregimus.livejournal.com
ЖЖ ведь ведь из себя open source, можно загрузить и посмотреть, если так интересно… :-)

(no subject)

2010-04-10 01:03 (UTC)
Posted by [identity profile] evil-gryphon.livejournal.com
да, это я забыл :( устал

(no subject)

2010-04-10 08:01 (UTC)
Posted by [identity profile] ivanstor.livejournal.com
Ну, положим, современные ширпотреб диски обеспечивают линейную скорость чтения/записи не 40 Мб/сек, а более 100 Мб/сек. Это с физического диска на физический диск. Серверные ещё бодьше, раза в полтора.
Камень преткновения не столько скорость последовательного чтения/записи, сколько время доступа к произвольным данным, т.е. для винчестеров — время позиционирования головки. Именно из-за этого у них резко падает скорость операций с большим количеством мелких файлов, порой на 3 порядка.
А вообще Вы правы, SSD выглядят привлекательно, если бы стоили ещё поменьше...

(no subject)

2010-04-10 08:33 (UTC)
Posted by [identity profile] fregimus.livejournal.com
Да, похоже, я отстал от жизни. Barracuda 7200.12 — 125 МБ/с sustained. Отчего ж виста такая медленная-то?

(no subject)

2010-04-18 11:53 (UTC)
Posted by [identity profile] ole-vin.livejournal.com
Контроллер не делается узким местом, а становится узким местом. :)

Profile

fregimus: (Default)
fregimus

March 2014

S M T W T F S
       1
2 3456 78
910 1112 131415
16171819202122
23242526272829
3031     

Most Popular Tags

Page generated 2025-12-24 08:58

Expand Cut Tags

No cut tags