Блог компании HP → HP выпускает 10-петабайтную систему D2D
В прошлом году HP выпустила первые дисковые системы резервного копирования D2D на базе разработанной учеными HP Labs технологии дедупликации с выборочным индексированием StoreOnce.
Напомним, что главная изюминка выборочного индексирования StoreOnce – это ускорение обработки резервных копий за счет более эффективной организации поиска дубликатов в индексе устройства резервного копированию.
На очередном общеевропейском форуме заказчиков и партнеров HP, который в этом году проходил в столице Австрии в конце ноября, компания показала новую систему резервного копирования D2D корпоративного класса, в которой также используется дедупликация StoreOnce. Система HP B6200 масштабируется от 48 до 768 Тбайт физической емкости (384 двухтерабайтных полноразмерных дисков SAS) или 512 Тбайт полезной емкости и обеспечивает скорость резервного копирования до 28 Тбайт/час, что позволяет за стандартное восьмичасовое окно резервного копирования сохранить 224 Тбайт данных. Если учитывать, что StoreOnce способна уменьшить размер резервных копий до 20 раз, то максимальный объем резервных копий, которые можно хранить на этой системе, равен десяти петабайтам! HP B6200 оборудуeтся 4-16 десятигигабитными портами Ethernet и таким же количеством восьмигигабитных Fibre Channel.
Напомним, что главная изюминка выборочного индексирования StoreOnce – это ускорение обработки резервных копий за счет более эффективной организации поиска дубликатов в индексе устройства резервного копированию.
На очередном общеевропейском форуме заказчиков и партнеров HP, который в этом году проходил в столице Австрии в конце ноября, компания показала новую систему резервного копирования D2D корпоративного класса, в которой также используется дедупликация StoreOnce. Система HP B6200 масштабируется от 48 до 768 Тбайт физической емкости (384 двухтерабайтных полноразмерных дисков SAS) или 512 Тбайт полезной емкости и обеспечивает скорость резервного копирования до 28 Тбайт/час, что позволяет за стандартное восьмичасовое окно резервного копирования сохранить 224 Тбайт данных. Если учитывать, что StoreOnce способна уменьшить размер резервных копий до 20 раз, то максимальный объем резервных копий, которые можно хранить на этой системе, равен десяти петабайтам! HP B6200 оборудуeтся 4-16 десятигигабитными портами Ethernet и таким же количеством восьмигигабитных Fibre Channel.
Linux для всех → Почти линейное увеличение производительности bzip2 на многопроцессорных системах
В Linux часто используется сжатие с помощью gzip и bzip2. Они оба обеспечивают хорошую плотность сжатия, и удобны в использовании. При этом bzip2 сжимает большинство файлов эффективнее — но, с другой стороны, работает медленнее, чем более традиционные gzip или zip.
Но можно получить эффективность bzip2, при этом существенно увеличив скорость. Речь идёт об утилите pbzip2 — Parallel BZIP2. В обычном случае при использовании bzip2 задействуется только одно процессорное ядро, в то время как на современных системах их может быть 2, 4, или, например, 8.
Pbzip2 может использовать сразу несколько процессорных ядер, что приводит, по заявлению авторов, к почти линейному увеличению производительности. Сжатые файлы, которые создаёт pbzip2, полностью совместимы с bzip2 1.0.2 и более новыми версиями bzip2 (также есть утилита pigz, которая, в свою очередь, является многопоточной реализацией gzip — спасибо altexxx).
Ниже результат тестирования скорости сжатия участка SQL-файла размером 1000M (dd if=dump.sql of=testfile bs=1M count=1000) на компьютере с двумя процессорами Intel Xeon E5520 (4 ядра, 8 потоков, тактовая частота 2,26 ГГц):
Как видно из результатов тестирования, pbzip2, работающий в 4 потока, приблизительно в 3,6 раз быстрее, чем bzip2, работающий в один поток — что действительно является почти линейным увеличением производительности.
При этом pbzip2, работающий в 16 потоков, оказался медленнее, чем pbzip2, использующий 4 потока — вероятно, из-за скорости выполнения операций ввода/вывода. Также смотрите дополнительные тесты в комментариях (спасибо tristan и bliznezz) — в том числе, с использованием tmpfs-раздела в оперативной памяти.
Используется pbzip2 примерно так же, как и просто bzip2, но есть некоторые дополнительные функции, например вывод прогресса выполнения операции в процентах.
Но можно получить эффективность bzip2, при этом существенно увеличив скорость. Речь идёт об утилите pbzip2 — Parallel BZIP2. В обычном случае при использовании bzip2 задействуется только одно процессорное ядро, в то время как на современных системах их может быть 2, 4, или, например, 8.
Pbzip2 может использовать сразу несколько процессорных ядер, что приводит, по заявлению авторов, к почти линейному увеличению производительности. Сжатые файлы, которые создаёт pbzip2, полностью совместимы с bzip2 1.0.2 и более новыми версиями bzip2 (также есть утилита pigz, которая, в свою очередь, является многопоточной реализацией gzip — спасибо altexxx).
Ниже результат тестирования скорости сжатия участка SQL-файла размером 1000M (dd if=dump.sql of=testfile bs=1M count=1000) на компьютере с двумя процессорами Intel Xeon E5520 (4 ядра, 8 потоков, тактовая частота 2,26 ГГц):
Как видно из результатов тестирования, pbzip2, работающий в 4 потока, приблизительно в 3,6 раз быстрее, чем bzip2, работающий в один поток — что действительно является почти линейным увеличением производительности.
При этом pbzip2, работающий в 16 потоков, оказался медленнее, чем pbzip2, использующий 4 потока — вероятно, из-за скорости выполнения операций ввода/вывода. Также смотрите дополнительные тесты в комментариях (спасибо tristan и bliznezz) — в том числе, с использованием tmpfs-раздела в оперативной памяти.
Используется pbzip2 примерно так же, как и просто bzip2, но есть некоторые дополнительные функции, например вывод прогресса выполнения операции в процентах.
JAVA → Java. Остановись задача из песочницы
Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.
.NET → Барьеры памяти и неблокирующая синхронизация в .NET из песочницы
Введение
В этой статье я хочу рассказать об использовании некоторых конструкций, применяющихся для осуществления неблокирующей синхронизации. Речь пойдёт о ключевом слове volatile, функциях VolatileRead, VolatileWrite и MemoryBarrier. Мы рассмотрим, какие проблемы вынуждают нас воспользоваться этими языковыми конструкциями и варианты их решения. При обсуждении барьеров памяти вкратце рассмотрим модель памяти .NET.
Perl → Многопоточность в Perl, или Как я посмотрел ролик о съёмках Warehouse 13
Всё началось с того, что я наткнулся на видео, которое рассказывало о съёмках одного из моих любимых сериалов, Warehouse 13:
www.aoltv.com/2009/07/10/behind-the-scenes-of-warehouse-13/
Клёвые штуковины в стиле «стимпанк», рассказ о взаимовыручке и дружбе, и лёгкая волшебная атмосфера, уводящая от серых будней — вот, чем мне нравится этот сериал. И вообще мне не менее интересно, чем сам фильм, бывает смотреть, как снимают этот фильм.
Но, как принято на сайте AOL TV, видео оказалось доступно только жителям US. Зачем накладывать такие ограничения — я не могу взять в толк. Где и какая жаба их душит, непонятно.
Но такая мелочь меня не могла остановить.
Программирование → Об оценке потенциала распараллеливания программ
Как известно, для оценки потенциала распараллеливания программы существуют два старых добрых закона: Закон Амдала и Закон Густавсона — Барсиса, первый из которых оценивает максимально возможное ускорение программы за счёт распараллеливания, а второй увеличение количества работы сделанной за тоже время. Оба закона используют 2 параметра — это P (доля параллельных расчётов в программе) и N (число процессоров/потоков). В этой статье я хочу показать возможность использования ещё одного параметра для более точной оценки.
C++ → Заметки о синхронизации. Deadlock
В наше суровое время, когда мощности процессоров перестали расти ввысь( частота ) и начали расти вширь( число потоков ), проблема синхронизации стоит как нельзя остро. Столкнувшись с этой проблемой на практике, я на себе ощутил, что задача эта намного сложнее, чем кажется на первый взгляд, и какое число подводных граблей она скрывает. В процессе работы над этой проблемой, у меня родилось несколько интересных паттернов, с которым я хочу познакомить хабрасообщество.
Системное программирование → Преимущества безблокировочного алгоритма — не только и не столько в производительности
Рассчитываю, что заключительный пост серии — в отличие от трёх предыдущих, оказавшихся, по-видимому, чересчур хардкорными — вызовет у хабрапублики не только филологический интерес.
Один из комментаторов серии постов Чена про безблокировочные алгоритмы поинтересовался, в каких условиях эти более сложные алгоритмы существенно превосходят по производительности такие простые примитивы блокировки, как критические секции.
Он совершенно прав, что переход от простого алгоритма к сложному должен быть оправдан замерами производительности: если простой алгоритм удовлетворительно справляется со своей задачей, то нечего искать добра от добра.
Но преимущества безблокировочной синхронизации не сводятся лишь к улучшенной, по сравнению с привычными примитивами блокировки, производительности. (Далее в этом посте мы увидим, как можно получить эти неочевидные преимущества, не переходя на полностью безблокировочную синхронизацию.)
Один из комментаторов серии постов Чена про безблокировочные алгоритмы поинтересовался, в каких условиях эти более сложные алгоритмы существенно превосходят по производительности такие простые примитивы блокировки, как критические секции.
Он совершенно прав, что переход от простого алгоритма к сложному должен быть оправдан замерами производительности: если простой алгоритм удовлетворительно справляется со своей задачей, то нечего искать добра от добра.
Но преимущества безблокировочной синхронизации не сводятся лишь к улучшенной, по сравнению с привычными примитивами блокировки, производительности. (Далее в этом посте мы увидим, как можно получить эти неочевидные преимущества, не переходя на полностью безблокировочную синхронизацию.)
Системное программирование → Беззахватные алгоритмы: модель «сделай, запиши,(поручи другому)»
Следуя совету хабрапублики, пробую новый вариант перевода термина "lock-free"
В прошлый раз мы видели «беззахватный по духу» алгоритм, где захват был реализован так, что поток, обращающийся к захваченным данным, не ждёт их освобождения, а отправляется «обходным путём» (вычисляет требуемый результат, не пользуясь услугами кэша). В своём следующем посте Реймонд объясняет, как данный алгоритм можно усовершенствовать на случай, когда «обходного пути» нет. Алгоритм, однако, остаётся беззахватным: каждый поток продолжает работать, не дожидаясь освобождения захваченных данных.
В общей переменной теперь нужны два служебных бита: вдобавок к флагу захвата, как в прошлом примере, — флаг «поручена новая работа»; а если порученная работа сложная, то кроме флага, нужно будет где-то хранить ещё и её параметры. Например, в общей переменной можно хранить указатель на (выравненный в памяти) объект с параметрами, а в свободных младших битах указателя — два названных флага.
Перед выполнением действия над объектом, первым делом мы его захватываем, атомарно устанавливая соответствующий флаг. Если окажется, что объект уже был захвачен, — поручим выполнение нашего действия захватившему потоку, установив второй флаг.
Если же объект удалось захватить, то после завершения работы с ним снимаем флаг захвата и одновременно проверяем, не поручили ли нам новую работу. (Т.е. не было ли обращений к объекту за то время, пока мы его держали захваченным.) Если есть работа, то мы выполним и её; и так далее, пока однажды при разблокировке объекта отложенной работы не окажется. Мы не вправе оставить объект в состоянии «не захвачен, но есть работа».
В прошлый раз мы видели «беззахватный по духу» алгоритм, где захват был реализован так, что поток, обращающийся к захваченным данным, не ждёт их освобождения, а отправляется «обходным путём» (вычисляет требуемый результат, не пользуясь услугами кэша). В своём следующем посте Реймонд объясняет, как данный алгоритм можно усовершенствовать на случай, когда «обходного пути» нет. Алгоритм, однако, остаётся беззахватным: каждый поток продолжает работать, не дожидаясь освобождения захваченных данных.
В общей переменной теперь нужны два служебных бита: вдобавок к флагу захвата, как в прошлом примере, — флаг «поручена новая работа»; а если порученная работа сложная, то кроме флага, нужно будет где-то хранить ещё и её параметры. Например, в общей переменной можно хранить указатель на (выравненный в памяти) объект с параметрами, а в свободных младших битах указателя — два названных флага.
Перед выполнением действия над объектом, первым делом мы его захватываем, атомарно устанавливая соответствующий флаг. Если окажется, что объект уже был захвачен, — поручим выполнение нашего действия захватившему потоку, установив второй флаг.
Если же объект удалось захватить, то после завершения работы с ним снимаем флаг захвата и одновременно проверяем, не поручили ли нам новую работу. (Т.е. не было ли обращений к объекту за то время, пока мы его держали захваченным.) Если есть работа, то мы выполним и её; и так далее, пока однажды при разблокировке объекта отложенной работы не окажется. Мы не вправе оставить объект в состоянии «не захвачен, но есть работа».
Системное программирование → Беззамочные алгоритмы: ненастойчивый кэш
(Тот факт, что русского перевода понятию «lock-free» в литературе ещё не устоялось, — нисколько меня не убеждает, что такого перевода не должно быть.)
Предположим, анализ производительности вашего приложения выявил, что существенная часть процессорного времени тратится в некой вычислительной функции, и более того, эта функция многократно вызывается с одними и теми же параметрами — выполняя одинаковые вычисления вновь и вновь. Напрашивается простая оптимизация — кэш из одной записи, в котором бы хранились исходные данные и результат последнего вычисления.
Само собой, этот код потоконебезопасен: если один поток находится внутри вызова
Простое решение — заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем,
Посмотрим, как можно реализовать наш кэш беззамочно.
Предположим, анализ производительности вашего приложения выявил, что существенная часть процессорного времени тратится в некой вычислительной функции, и более того, эта функция многократно вызывается с одними и теми же параметрами — выполняя одинаковые вычисления вновь и вновь. Напрашивается простая оптимизация — кэш из одной записи, в котором бы хранились исходные данные и результат последнего вычисления.
BOOL IsPrime(int n)
{
static int nLast = 1;
static BOOL fLastIsPrime = FALSE;
// если значение параметра не изменилось с прошлого раза,
// воспользуемся готовым результатом
if (n == nLast) return fLastIsPrime;
// вычислим и запомним новый результат
nLast = n;
fLastIsPrime = slow_IsPrime(n);
return fLastIsPrime;
}
Само собой, этот код потоконебезопасен: если один поток находится внутри вызова
slow_IsPrime(), то другой поток, вызвавший IsPrime(), застанет значения переменных nLast и fLastIsPrime несоответствующими одно другому.Простое решение — заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем,
nLast = 5, fLastIsPrime = TRUE, и два потока одновременно вызывают IsPrime(5), то совершенно ни к чему им выстраиваться в очередь: ничего не мешает им одновременно воспользоваться кэшированным значением.Посмотрим, как можно реализовать наш кэш беззамочно.