Доброго времени суток. Решил поделиться с вами способом в домашних условиях поддерживать на должном уровне здоровье наших любимых ноутбуков (нетбуков).
Есть одна страшная, а порой и гибельная угроза- перегрев! Многие из вас сталкиваются с тем, что ваш верный помощник обжигает колени, хотя непрерывно воет кулер, либо неплохо нагнетает температуру в уютный (может слегка пыльный) плед, которым вы укутали себя, а заодно и ноут. Тут-то стоит задуматься,- «А к чему бы это?». А ведет все к перегреву, внезапному отключению и отказу к призывам «включиться сейчас же и доиграть в игру». Не тут-то было- он включится только через определенный промежуток времени, в течение которого остынет он естественным путем. А бывает и не включаются, тогда прямая дорога в СЦ, ибо профилактика пациента уже не спасет. После диагностики выявится обычно или спаленный видеочип, либо перегретый мост. Что одно, что другое не очень приятно по цене ремонта. Так что давайте следить за своими устройствами и не доводить до крайних мер.

Последняя статья про классические примитивы синхронизации.

(Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

Сегодня мы немножко заглянем в процессор. Чуть-чуть.

По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

Но меня эта тема интересует не только с позиции программиста юзерленда, но и с позиции разработчика ядра, а так же и разработчика самих примитивов синхронизации. И тут уже различие принципиально.

Дело в том, что внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

Есть и ещё одно, семантическое различие. Мьютекс допускает и предполагает снятие нити с процессора, долгую остановку вызывающей нити. Мьютексом можно запереть объект на час или сутки, это приемлемо и нормально. Спинлок принципиально рассчитан только на кратчайшие приостановки, это всегда работа с неатомарным стейтом объекта. Присваивание группы переменных, небольшой цикл — это максимум того, что можно сделать под спинлоком.

Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

Как устроен спинлок?

Высокоскоростной интернет стал доступен практически везде: от кафе в центре Москвы до дикого пляжа на Адриатике. Теперь оставаться на связи стало очень просто — установил пару-тройку приложений на смартфон и можно отправляться на отдых в теплые края, не опасаясь, что нужный звонок, сообщение или e-mail пройдет мимо. При общении в социальных сетях в ответ на «Привет, ты здесь?», вполне нормальным может быть: «В бегах, наберу потом». Другое дело, если на интернет-коммуникации завязан бизнес – в любой момент нужно быть готовым ответить на входящий или сделать важный исходящий звонок (даже если ты едешь на мотобайке по Патайе).

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

Первого октября сего года мы рассказывали о новом поколении систем хранения данных HP 3PAR StoreServ. Под тем постом зашёл разговор о тестировании по стандартам Storage Performance Council. Для того чтобы такие тесты провести, нужно время и немалые усилия. Результаты испытаний одной из систем 3PAR были опубликованы 4 ноября. Если в двух словах, то СХД HPE 3PAR StoreServ 20850 All-Flash Array установила мировой рекорд в тесте SPC-2. Здесь можно посмотреть таблицу лидеров, здесь – ознакомиться с подробностями испытаний.

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



Чашка свежего мёда, только что из улья… Вкуснятина? Бесспорно.

В конце октября вышла новая версия HP Vertica. Команда разработчиков продолжила славные традиции выпуска строительной техники BigData и дала кодовое имя новой версии Excavator.

Изучив нововведения этой версии, я думаю, название выбрано верное: все что нужно для работы с большими данными у HP Vertica уже было реализовано, теперь же нужно балансировать и улучшать существующее, то есть копать.

Ознакомиться с полным списком нововведений можно в этом документе: http://my.vertica.com/docs/7.2.x/PDF/HP_Vertica_7.2.x_New_Features.pdf

Я же вкратце пройдусь по наиболее значимым с моей точки зрения изменениям.

Изменена политика лицензирования

В новой версии были изменены алгоритмы подсчета занимаемого размера данных в лицензии:

• Для табличных данных теперь при подсчете не учитывается 1 байт разделителя для числовых и дата-время полей;
• Для данных в зоне flex при подсчете размер лицензии считается, как 1/10 от размера загруженных JSON.

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

Добавлена официальная поддержка RHEL 7 и CentOS 7

Теперь можно будет разворачивать кластер Vertica на более современных ОС Linux, что думаю должно обрадовать системных администраторов.

Оптимизировано хранение каталога базы данных

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

Есть несколько вопросов, которые встают перед фрилансерами, использующими кредитки или карты-рассрочки перед выездом за границу. Один из важнейших — это средство хранения денег и платежей. Карты русских банков по ряду причин становятся неудобны при длительном пребывании за границей — например, в случае утери, блокировки и необходимости восстановления. Или, например, при необходимости завести новый счёт в другой валюте — не полетишь же специально в Россию за этим? В последнее время добавились и политические риски. Но в итоге всё сводится к вопросу чисто логистическому: как получить банковскую карту, находясь за пределами родной страны.

Привет, Хабр! В предыдущих статьях мы описали парадигму MapReduce, а также показали как на практике реализовать и выполнить MapReduce-приложение на стеке Hadoop. Пришла пора описать различные приёмы, которые позволяют эффективно использовать MapReduce для решения практических задач, а также показать некоторые особенности Hadoop, которые позволяют упростить разработку или существенно ускорить выполнение MapReduce-задачи на кластере.

Привет, Хабр! В предыдущей статье мы рассмотрели парадигму параллельных вычислений MapReduce. В этой статье мы перейдём от теории к практике и рассмотрим Hadoop – мощный инструментарий для работы с большими данными от Apache foundation.

В статье описано, какие инструменты и средства включает в себя Hadoop, каким образом установить Hadoop у себя, приведены инструкции и примеры разработки MapReduce-программ под Hadoop.

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



Ниже под катом — расшифровка нашей беседы для тех, кто видео не очень.

Visual Studio Code — редактор кода, с поддержкой более 30 языков программирования и форматов файлов, а так же обладающий рядом дополнительных, полезных возможностей.  
 
Инструмент вышел весной этого года, и ранее мы уже успели рассказать о базовых возможностях этого кроссплатформенного редактора. Напомню, что использовать VS Code можно на компьютерах под управлением Windows, OS X и Linux.
 
Однако, за полгода существования инструмент регулярно обновлялся и продолжает обновляться раз в месяц, расширяя свой функционал, список поддерживаемых языков, постоянно улучшая существующие возможности, основываясь на отзывах и пожеланиях пользователей.
 
Сегодня мы поделимся обзором следующих возможностей Visual Studio Code на примере использования в OS X: интеграция с Unity3D, Visual Studio Online, GitHub, а так же подробными видео-материалами по установке, настройке и комфортной работе с VS Code на Mac.

Не так давно Google выпустил версию 7.8 библиотеки Google Play Services. В числе мажорных нововведений представлен новый Mobile Vision API, состоящий из двух больших компонентов: Barcode API — для сканирования и распознавания различных штрих- и QR-кодов и обновленный Faces API — для поиска и трекинга лиц на картинках. Под катом познакомимся с Faces API, рассмотрим его основные возможности и напишем небольшое приложение.

Как вы могли заметить, у нас тут затишье. Но наш творческий поиск не прекращается, и первая октябрьская публикация будет посвящена ACO (Ant Colony Optimization)



Отдавая должное автору, мы не будем публиковать здесь последнюю часть статьи, содержащую пример на JavaScript, а предложим вам опробовать его на сайте оригинала. Под катом же вы найдете перевод теоретической части, доступно рассказывающей о тонкостях муравьиной оптимизации в различных сценариях.

Эта минипубликация — развёрнутый комментарий на публикацию о HackerSIM.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

В публикации рассмотрим как можно внедрить логирование jdbc операций в существующее приложение без его пересборки и перекомпиляции. Это даст возможность протоколировать параметры запросов, которые заполняет программа, и многие другие аспекты работы с jdbc.

Введение

На момент написания статьи большинство приложений на основе открытых данных (на официальных сайтах data.mos.ru/apps и data.gov.ru) представляют собой интерактивные справочники по инфраструктуре города или поселения с наглядной визуализацией и часто с опцией выбора оптимального маршрута. Цель этой и последующих публикаций состоит в том, чтобы привлечь внимание сообщества к обсуждению стратегий анализа открытых данных, в т.ч. направленных на прогнозирование, построение статистических моделей и извлечение информации, не представленной в явном виде. В качестве инструментария используется язык R и среда разработки RStudio.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Верный способ войти в историю – ответить, кто побеждает в шахматах при идеальной игре обеих сторон (белые, чёрные или дружба). Нужны ли гроссмейстеры и суперкомпьютеры, чтобы узнать истину? Или достаточно карандаша, бумаги и красивой идеи?

Математика вселяет надежду, ведь можно доказать существование объекта, не предъявляя его, найти ответ, не разъясняя глубинные причины, почему он именно такой.

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

В самом посте о задаче такого вопроса не поставлено. Однако уже в первом комментарии к нему пользователь mayorovp поднимает тему, а чуть ниже avfonarev сообщает о замечательной статье, раскрывающей тайну.

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

На этой неделе я начал читать бакалаврам Академического университета базовый курс по алгоритмам. Начинал я совсем с основ, и чтобы тем, кто с базовыми алгоритмами уже знаком, было чем заняться, я в начале пары сформулировал две, наверное, самые свои любимые задачки по алгоритмам. Давайте и с вами ими поделюсь. Решение одной из них даже под катом подробно расскажу. Но не отказывайте себе в удовольствии и не заглядывайте сразу под кат, а попытайтесь решить задачи самостоятельно. Обещаю, что у обеих задач есть достаточно простые решения, не подразумевающие никаких специальных знаний по алгоритмам. Это, конечно, не означает, что эти решения просто найти, но после пары один из студентов подошёл и рассказал правильное решение первой задачи. =) Если же вам интересно посмотреть на начало курса или порешать больше разных задач — приходите к нам на (бесплатный) онлайн-курс, который начнётся 15 сентября.

Задача 1. Дан массив A длины (n+1), содержащий натуральные числа от 1 до n. Найти любой повторяющийся элемент за время O(n), не изменяя массив и не используя дополнительной памяти.

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

Задача 2. Дана матрица nxn, содержащая попарно различные натуральные числа. Требуется найти в ней локальный минимум за время O(n).

Локальным минимумом матрицы называется элемент, который меньше всех своих четырёх соседей (или трёх, если этот элемент лежит на границе; или двух, если это угловой элемент). Обратите внимание, что от нас требуется линейное по n время, хотя в матрице квадратичное по n число элементов. Поэтому мы предполагаем, что матрица уже считана в память. И нам нужно найти в ней локальный минимум, обратившись лишь к линейному количеству её ячеек.

Под катом — решение первой задачи. Ещё раз призываю вас заглядывать под кат только после того, как порешаете задачу. По второй задаче могу какую-нибудь подсказку сказать.

Обычно при компиляции Java-файла получаются .class-файлы примерно того же размера, что и исходник. Меня заинтересовало, можно ли по небольшому исходнику сделать .class-файл, который больше, сильно больше исходника.

Можно поискать какие-то короткие конструкции языка, которые компилируются в длинные цепочки байткода, но линейный прирост меня не устраивал. Я сразу подумал про компиляцию finally-блоков: про неё уже писали на Хабре. Если вкратце, то для каждого finally-блока при непустом try-блоке создаётся минимум два варианта в байткоде: для случая нормального завершения try-блока и для случая завершения с исключением. В последнем случае исключение сохраняется в новую локальную переменную, выполняется код finally, затем исключение достаётся из локальной переменной и перебрасывается. А что если внутри finally снова разместить try-finally и так далее? Результат превзошёл все ожидания.