Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
обзор средств разработки для вычислений GpgpuCOMAQA.BY
Производительность современных графических процессоров растет гораздо быстрее производительности центральных и в настоящее время в некоторых задачах уже превосходит их на порядок. Поэтому для создания приложений с производительностью опережающей решения конкурентов компании все чаще начинают использовать этот ресурс. GPGPU - неспециализированные (т.е. связанные не только с графикой) вычисления на графических процессорах. Рассмотрим актуальные технологии для написания GPGPU приложений (CUDA, OpenCL, OpenACC и не только). В качестве критериев оценки будут выступать - функционал, скорость разработки, спектр поддерживаемых устройств, языков и компиляторов, удобство отладки и профилирования. Примером практического применения GPGPU выступит реализация алгоритма подавления шума на изображениях.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Тезисы - http://www.highload.ru/2015/abstracts/1964.html
обзор средств разработки для вычислений GpgpuCOMAQA.BY
Производительность современных графических процессоров растет гораздо быстрее производительности центральных и в настоящее время в некоторых задачах уже превосходит их на порядок. Поэтому для создания приложений с производительностью опережающей решения конкурентов компании все чаще начинают использовать этот ресурс. GPGPU - неспециализированные (т.е. связанные не только с графикой) вычисления на графических процессорах. Рассмотрим актуальные технологии для написания GPGPU приложений (CUDA, OpenCL, OpenACC и не только). В качестве критериев оценки будут выступать - функционал, скорость разработки, спектр поддерживаемых устройств, языков и компиляторов, удобство отладки и профилирования. Примером практического применения GPGPU выступит реализация алгоритма подавления шума на изображениях.
Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...Ontico
Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений.
Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map.
В докладе я отвечу на вопросы:
+ Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов?
+ Зачем вам может захотеться распилить JVM на несколько частей?
+ Как добиться от key-value хранилища медианной latency меньше 1 микросекунды?
+ Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений?
Развею миф о том, что Java — это медленно :)
Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Строим сервисы на базе Nginx и Tarantool / Василий Сошников, Андрей Дроздов (...Ontico
Слушатели этого доклада получат представление о том, как построить отказоустойчивое, быстрое, простое и легко масштабируемое решение на базе Nginx и Tarantool.
Коротко о главном:
+ Обзор внутреннего устройства шардинга в Tarantool.
+ Обзор Tarantool upstream модуля для Nginx.
+ Результаты нагрузочного тестирования Tarantool шардинга в связке с Nginx модулем.
+ Live-demo: распределенное отображение графа категорий Wikipedia в СУБД Tarantool с единой точкой входа и возможностью реалтайм поиска по категориям.
В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
"YT — новая платформа распределённых вычислений". Максим Бабенко, Яндекс. Yandex
На протяжении трёх лет мы проектировали, разрабатывали и внедряли YT — новую платформу для хранения и обработки больших объёмов данных. Она создавалась как альтернатива MapReduce-подобной системы, которая используется в Яндексе с 2008 года. При этом требовалось повысить её эффективность, доступность и масштабируемость. Задачу усложнял огромный объём унаследованного кода клиентов, с которыми необходимо было сохранить совместимость, а также наличие общепризнанных открытых альтернатив (например, платформы Hadoop). Поскольку YT изначально проектировалась по принципу «больше чем MapReduce», в её дизайне выделяется набор компонент, допускающих повторное использование: подсистема распределённого консенсуса и репликации состояния, дерево метаданных, blob-хранилище и другие. В докладе я дам краткий обзор архитектуры новой системы, расскажу о нескольких ключевых компонентах, а также поделюсь опытом, полученным в процессе разработки и внедрения. В завершение, перечислю приоритетные направления дальнейшего развития YT.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серве...Ontico
В процессе обновления высоконагруженных серверов раздачи видео (40Gbit/s с каждого сервера) со старого OpenSuSE 10.2 на новый CentOS 7 (время между релизами — 7 лет) мы столкнулись с рядом проблем — необъяснимый свопинг и запуски OOM killer, неравномерное распределение нагрузки по ядрам, обрывы соединений, скачки системной нагрузки на CPU.
В докладе будет рассказано о том, как мы боролись с этими проблемами и какие технологии для этого использовали.
Строим сервисы на базе Nginx и Tarantool / Василий Сошников, Андрей Дроздов (...Ontico
Слушатели этого доклада получат представление о том, как построить отказоустойчивое, быстрое, простое и легко масштабируемое решение на базе Nginx и Tarantool.
Коротко о главном:
+ Обзор внутреннего устройства шардинга в Tarantool.
+ Обзор Tarantool upstream модуля для Nginx.
+ Результаты нагрузочного тестирования Tarantool шардинга в связке с Nginx модулем.
+ Live-demo: распределенное отображение графа категорий Wikipedia в СУБД Tarantool с единой точкой входа и возможностью реалтайм поиска по категориям.
В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.
Оптимизации уровня CPU, Андрей Акиньшин (JetBrains)Ontico
В современном мире многие разработчики перестали стараться писать высокопроизводительный код. Порой их можно понять: в наше время прекрасных облачных решений дешевле докупить дополнительных серверов, чем тратить время на оптимизацию кода. Но что, если у вас нет такой возможности? Что, если для текущей задачи вы ограничены одной машиной или даже одним потоком?
В этом докладе мы обсудим некоторые подходы, которые помогают выжимать максимум производительности из современного железа и позволяют разгонять программы, которые, казалось бы, разогнать нельзя. В числе прочего будем обсуждать следующие вещи: CPU cache, Instruction Level Parallelism, False sharing, Branch Prediction, SEE/AVX instructions и т.д.
Causas de mortalidade de cabritos e borregosgecoufba
O documento discute as principais causas de mortalidade em cordeiros, desde o nascimento até o desmame. As causas incluem deficiências nutricionais, parasitas, problemas reprodutivos nas ovelhas, baixo peso ao nascer, infecções e doenças como toxemia da gestação. Fatores como condições de alojamento, manejo, alimentação e aleitamento também influenciam a sobrevivência dos cordeiros.
overview of development tools for computing Gpgpucorehard_by
Производительность современных графических процессоров растет гораздо быстрее производительности центральных и в настоящее время в некоторых задачах уже превосходит их на порядок. Поэтому для создания приложений с производительностью опережающей решения конкурентов компании все чаще начинают использовать этот ресурс. GPGPU - неспециализированные (т.е. связанные не только с графикой) вычисления на графических процессорах. Рассмотрим актуальные технологии для написания GPGPU приложений (CUDA, OpenCL, OpenACC и не только). В качестве критериев оценки будут выступать - функционал, скорость разработки, спектр поддерживаемых устройств, языков и компиляторов, удобство отладки и профилирования. Примером практического применения GPGPU выступит реализация алгоритма подавления шума на изображениях.
Мы покажем, как можно перенести разработанные алгоритмы для работы с Big Data с минимальными изменениями исходных программ. Рассмотрим возможности по распараллеливанию счета на многоядерных процессорах (вычислительных кластерах) и графических процессорах, поддерживающих CUDA.
Сейчас OpenStack на слуху, но детальных отзывов и описаний дизайна инфраструктуры все еще не много. Постараемся немного упростить задачу для тех, кто еще только планирует развертывание инфраструктуры виртуализации, и расскажем, как это делали мы в некоторых наших проектах:
погрузимся в нюансы реализации окружения OpenStack в боевой среде;
поговорим об отказоустойчивости;
рассмотрим варианты организации резервного копирования;
обратим внимание на конфигурацию «железок»: СХД и сети.
1. Обзор библиотек с поддержкой CUDA
Анатолий Свириденков
(сodedgers.com)
Блог: http://bit.ly/cuda_blog
2. 2
Проблематика
Где нужна вычислительная мощность:
- Ускорение вычислений
- Переход в реальное время
- Разгрузка CPU
- Улучшение качества
3. 3
Бибилиотеки и алгоритмы
Применение библиотек с GPU:
- Обработка видео и изображений
- Вычисления
- Прочие причины
http://www.nvidia.ru/object/cuda_app_tesla_ru.html
4. 4
Обработка видео
OpenCV 2.2 — обработка изображения и компьютерное
зрение
NPP — nVidia performance primitive
9. 9
CUFFT - быстрые преобразования Фурье
Размерность Исходные данные Результат
Вещественные числа
1D
Комплексные числа
Вещественные числа
2D Комплексные числа
Комплексные числа
Вещественные числа
3D
Комплексные числа
http://developer.download.nvidia.com/compute/cuda/3_1/toolkit/docs/CUFFT_Library_3.1.pdf
10. 10
CUSPARSE - операции над разрежеными матрицами и
векторами
Ускорение по сравнению с MKL от 2 до 7 раз
http://developer.download.nvidia.com/compute/cuda/3_2/toolkit/docs/CUSPARSE_Library.pdf
12. 12
Прочие библиотеки
CUDPP — примитивы параллельной обработке данных
Thrust — STL для CUDA
CUDA.NET — поддержка CUDA в C#
13. 13
CUDPP
Отталкивается от данных:
- Сортировка, поиск
- Умножение разреженых матриц и векторов
- Генерация случайных чисел
http://groups.google.com/group/cudpp?pli=1
14. 14
Thrust
STL style:
- Сортировка, поиск
- Генерация случайных чисел
- Поддержка коллекций: tuple, vector и list
- Поддержка алгоритмов: scan, reduce, sum, count_if и т.д.
http://code.google.com/p/thrust/
15. 15
CUDA.NET
- Исполнение CUDA kernels в файлах *.cu
- Исполнение OpenCL ядер
- Поддержка CUFFT
- Поддержка CUBLAS
- Вызов функций OpenCV портированных на CUDA
http://www.hoopoe-cloud.com/files/cuda.net/2.0/CUDA.NET_2.0.pdf
