Блог:Виталий Филиппов

Технические вопросы и вменяемые заметки от меня, Виталика.

У меня, конечно, уже есть блог Ljuser.gifsimply_a_man.

2020-01-14 Про "эффективные" "надёжные" микросервисы

На хайлоад в этом году не ходил, но услышал от коллеги про доклад … про вот этот вот доклад (на хайлоаде был он же):

https://2019.jokerconf.com/2019/talks/4wj9og0tij3wpxe3ourovr/

Вкратце: выходит дядька и говорит, что вот, в типичной веб-архитектуре с БД, memcached и stateless приложением очень большие затраты на маршалинг и демаршалинг [дядя реальный олд, раз сериализация у него маршалинг — но на это забьём]. Конкретно, до 85 % времени на это дело якобы уходит.

Поэтому они взяли Кассандру, засунули её прямо в Java процесс с приложением, и общаются с ней локально. Типа она распределённая, поэтому всё остаётся отказоустойчиво — она синхронизируется с другими нодами. И типа поэтому всё хорошо.

И вот с чего я тут охреневаю — это с 85 % затрат на сериализацию. Ну треш же какой-то! Ладно, ява, ну и что — https://github.com/fabienrenaud/java-json-benchmark - вот бенч разных библиотек JSON для явы. Самая быстрая даёт ~800 тысяч разборов и ~1.5 млн кодирований по 1 КБ в секунду, да и банальный Jackson не сильно отстаёт: ~500к / ~1 м.

Оказывается, 85 % это ссылка на статью: https://research.google/pubs/pub48030/. Статья тоже кривая. Не объясняя, ЧТО они тестировали, они действительно приводят цифры в оверхед сериализации в 45 % CPU и 85 % передачи лишних данных по сети и на основании этого агитируют за написание stateful бэкенда.

Если присмотреться внимательнее, там, правда, есть пометка:

Finally, our experiments in Section 3 show that if only part of the record is needed (10 %), RInK stores incur both extra CPU (46 %) and network (85 %) costs

For example, consider anapplication that caches the address books for all online usersin aRInKstore: for each user, the address book is stored as asingle key-value pair. If a request arrives from Alice to readBob’s phone number from her address book, all of Alice’scontacts must be fetched and unmarshalled, even thoughonly a small portion of the data is needed.

Б**дь! Ну так не надо так писать, чтобы для чтения 1 номера телефона приложение читало всю адресную книгу!!!

А к дядьке этому у меня один вопрос — он сам вообще что-то сравнивал? Или как всегда — «потому что можем»?

Каждый раз немного удивляюсь от их микросервисо-джабба-страданий… они же ими балуются ещё с тех пор, когда их не называли микросервисами. И в страданиях изобретали сначала собственный java-сериализатор, потом собственный кэш, сначала борясь с gc, а потом забив и уйдя куда-то на разделяемую память. Вылысыпыдысты.

Ну ладно. «Ночью через лес», когда файловое хранилище на postgresql изобретал, тоже сначала бодрый был.

2019-02-06 Ночью через лес

Про доклад «Ночью через лес»… https://youtu.be/oMQLR-BhnJU

…по болоту на тандемном велосипеде с крыльями.

Ко мне тут (4.02.2019) однокурсник обратился с вопросом — типа он там щас работает в этой конторе. У них хранилище ФАЙЛОВ (30-50 тб, правда, в основном мелких) в Кассандре. Было то ли на 4 то ли на 8 серверах, диски в RAID-ах и поверх bcache.

Щас они этот кластер — внимание! — переместили в один сервер в докеры, оставив 16 дисков и 16 узлов (но убрав bcache), то есть теперь 16 кассандр в одном сервере (зачем? потому что так дешевле).

И вот короче встал вопрос: извне всего ~137 rps, объекты по <= 64 кб. 64кб*137 = всего где-то ~9 мбайт/с. Но при этом 16 дисков (HDD) загружены по самое не балуйся, на каждом чтение >= 100 мбайт/с. Вопрос: какогохуя?)))

Я его спросил — а на#уя в кассандре? — а он мне скинул ссылку на этот доклад — я открыл, начал смотреть и думаю — б#я! я же помню этого мужика!

И точно — он в 2012 году на highload рассказывал, как пи#дато файлы в postgres-е хранить: Highload-2012: Отчёт Виталия Филиппова#Спасение 6 млн файлов в условиях полного Хецнера / Даниил Подольский, Дмитрий Симонов (Setup.ru)

То есть типа сначала у них всё типа было просто в локальных ФС на двух серверах и синхронизировалось rsync-ом. Потом у них кончилось место на серверах, обход дерева директорий стал занимать очень много времени (8 часов), и они засунули файлы в postgresql с мастер-мастер репликацией.

Потом оказалось, что крупные файлы неудобно хранить просто в поле и они их засунули в блобы. А потом обнаружили, что блобы не попадают в репликацию! Ну и в целом, что всё это грузит постгрю. Тогда они вынули из postgresql всё, что было больше 64к и сунули в LeoFS. LeoFS — это такая попытка сделать Ceph, но очень хреновая.

Потом в leofs кончилось место, они попробовали добавить пару серверов… и leofs развалился на хрен. Они позвонили японцам-авторам, те их час послушали и сказали «простите, у нас кончилось время, до свидания».

Они с помощью видимо такой-то матери убрали добавленные сервера обратно — и оно опять работало, пока в leofs не кончилось место окончательно.

И тут… им пришла свежая мысль — засунуть это всё в aerospike. Засунули, на 8 серверов. И оно вроде опять заработало, да ещё и кластеризация автоматическая появилась. Про это был доклад уже в 2015 году.

Продолжение я знаю уже из вопроса однокурсника: Aerospike их, видимо, тоже не устроил и сейчас у них всё это уже в кассандре!

И вот этот дядя на Highload нам рассказывает, что Ceph, который под это идеален, они пробовали и им было медленно (да ещё и «ребаланс по каждому чиху, при котором кластер вообще нельзя эксплуатировать»)… Жопой чую — у них там и сеть была 1G, конечно, какой уж тут ребаланс…

И это всё на продакшне. Эпично. Там ещё гениальный вопрос в конце доклада есть — типа, а вот когда у вас кончилось место в 2 серверах — почему вы… просто не добавили ещё 2?))))))) — «а чо, так можно было?…»

Просто плотно проработав последние несколько лет с Ceph-ом слушать это мегаржачно! Это вот Ceph значит медленный, а кассандра, которая грузит все диски на 100 % — быстрая? И это у них ещё записи нет. Была бы запись, было бы примерно как с KVStore-ом, когда 80 % i/o занимал compaction (KVStore — это промежуточная попытка апгрейда хранилки в ceph между filestore и bluestore).

Бэкапы он тоже не делает — ну, типа, реплика же есть, да и откуда ещё 30 тб взять.

Третья серия — это второй доклад 2015 года — https://youtu.be/bOqSexPzSIE?t=1702 - в нём он уже не такой весёлый и просто рассказывает, как всё сложно с этими вашими файловыми хранилищами.

2018-06-27 Тестирование различных способов подключения SSD для Ceph

Задача: проверить гипотезу, что дешёвые SSD без конденсаторов можно подключать к системе через RAID контроллер с батарейкой для получения приличных IOPS-ов в Ceph (хотя это и извращение).

TL;DR: похоже, можно. IOPS-ы растут, а данные потерять не удалось. Но, конечно, это всё равно в некоторой мере стрельба в ногу, поэтому лучше просто купить недорогие Enterprise SSD с «advanced power loss protection» типа Micron 5100/5200.

UPD: Предложенную идею официально считать дичью, делать так не надо.

→ продолжить чтение…

2018-06-26 Пенсионная математика

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

Можно заюзать вот такую математику.

Если предположить, что:

  • пенсии субсидируются исключительно налогом с зарплат
  • средняя зарплата в стране 36000 руб
  • средняя пенсия в стране 14000 руб
  • количество пенсионеров 30 %
  • количество работающих 54 %

(все цифры взяты из интернетов, предположим что близки к реальности)

Тогда налог будет 14/36*30/54 = 21,6 %

Что характерно, весьма близко к реальности — реальность 22 %.

С одной стороны, правда, в среднем в реальности меньше, так как всякие льготы и «регрессивная» шкала налога. С другой стороны, вроде и ПФР субсидируется не только налогом с зп. Ну и сам очевидно жрёт — но поисследовать сколько он жрёт вопрос к исследователям типа ФБК ну и не знаю,… ФСБ там.

В общем, если так смотреть — то вроде:

  • по мне как-то не видно явной необходимости повышать возраст.
  • реальная проблема России в низких зарплатах. из-за низких зарплат и пенсии низкие.

А, да, и ещё соответственно накопительная система была в принципе тоже логичным решением проблемы — тогда типа убралось бы «усреднение» — у кого зп большая, была бы и пенсия большая (в теории), а у кого маленькая — была бы и пенсия маленькая. Но «получилось как всегда», так как у будущих бабушек в усть-задрищенске зарплата мизерная, а содержать их надо (ну в принципе логично что надо — вроде там это… помощь незащищённым слоям населения и всё такое). Вот и закопали её видимо.

Но по сути правильное решение — постараться обеспечить рост средней з/п по стране + оптимизировать нецелевые расходы ПФР (в России же живём, наверняка там их можно найти) + продолжать сколько-то субсидировать, наверное.

И ещё на самом деле сам этот налог — для мелкого бизнеса идиотский совершенно. Вот допустим ты ИП и работаешь на себя — платишь только фиксированный взнос 28000 в год в ПФР и 6 % налога с выручки.

А потом вдруг хочешь нанять ОДНОГО сотрудника и хренак!!! Сразу 43 % налога!!! Из которых 22 % это ПФР, 8 % прочее и 13 % НДФЛ. И ещё твои 6 % тоже ведь никуда не деваются.

Как-то это тупо, разрыв слишком огромный. Выходит либо никого не оформляй и работай в чёрную, либо оформляй на 10000 руб оклад и снижай ту самую среднюю з/п по стране, либо ищи где-то лишних 43 % бабла, что для мелкого бизнеса весьма проблематично.

Какой-то более мягкий переход должен быть, тогда мелочь повылезает из чёрных/серых окладов и небось и средняя з/п тоже повысится и фактические отчисления в ПФР…

2018-01-01 Всё-таки Redux - отстой

Всё-таки Redux кривоват.

Ну просто вот пример — есть там, не знаю, в приложении таблица «города», и надо сделать компонент подсказки городов — автокомплит.

Есть библиотечный автокомплит, поверх к нему, соответственно, надо дописать функцию, которая подгружает сами данные, чтобы дальше использовать в ДВУХ и более местах приложения БЕЗ копипастинга. Например просто два поля подряд даже вставить — ну типа город1, город2, или город юзера / город компании, или ещё что-нибудь.

Состояние у автокомплита — это:

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

И действия:

  1. обработать изменение введённого текста (подождать 200мс, отправить запрос на подгрузку опций)
  2. обработать ответ на запрос подгрузки — залить опции в состояние
  3. обработать событие выбора опции — залить выбранное значение в состояние

Вопрос: КУДА всё это пихать?

Если Redux, то Redux говорит, что вроде как ВСЁ пихать в Store. Но Store глобальный => получается, что когда ты вставляешь в ДВА или более места свой компонент, ты должен:

  1. заставить его брать данные из РАЗНЫХ мест из стора
  2. заставить его отправлять Reducer’у какие-то ДРУГИЕ действия (по-другому именованные видимо — типа «field1_load_autocomplete», «field2_load_autocomplete»)
  3. потом ещё и заставить Reducer(ы) их обрабатывать

Получается, что по идее ради 1 и 2 ты, как минимум, занимаешься копипастингом mapStateToProps/mapDispatchToProps/connect(), а ради 3 ты ещё и копипастишь обработчик action’а, или подключение обработчика, возможно через combineReducers(), но всё равно тебе как минимум один action в нём придётся как-то переопределить — чтобы значение-то итоговое сохранять туда, куда нужно.

Вопрос: НА#УЯ всё это надо?

Если с голым React’ом ты просто все эти обработчики ляпнешь прямо в компоненте, и стейт будет там же, а значение наружу будет передаваться колбэком.

И в этом случае чтобы повторно использовать компонент ты как бы да, просто напишешь <CityAutocomplete value=... onChange=... />.

Не, я понимаю, что ВРОДЕ типа кажется круто полностью отделить работу с данными от рендера, ВРОДЕ типа круто при серверсайд рендеринге (подгрузил состояние и продолжил с того же момента), при извращениях типа живой отладки с сохранением состояния при изменении кода…

Но если при этом теряется переиспользуемость компонентов — это какое-то фуфло.

Короче, резюме: React, похоже, надо юзать голый, БЕЗ Redux’а.

2017-12-14 История одного просветления, произошедшего пару лет назад

Надо запротоколировать — прикольная история.

Когда я на это напоролся, у меня было, собственно, открытие — я полностью прочувствовал, что PHP по дефолту не умеет обрабатывать 2 параллельных запроса от одного юзера.)))

Суть такая: в PHP сделано тупое, но надёжное решение для исключения параллельной записи данных одной сессии двумя процессами — сессия тупо блокируется на весь период от её открытия до закрытия. А открывается она обычно в начале запроса — а закрывается в конце.))

Следовательно, если никто ничего специально не предпринимал — 2 параллельных запроса от одного и того же юзера пхп выполнять не умеет :) ну то есть, например, невозможно параллельно открыть нескольких вкладок с одного сайта — они последовательно открываться будут.

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

И видимо, когда народ в PHP переключает сессию на redis и говорит, что всё стало «летать» — летать оно начинает именно потому, что redis хранилище сессий в пхп не делает блокировку — не то что это его фича — просто не умеет оно в блокировки :)

А вот теперь история, как я на это напоролся:

Ставил я VisualEditor (визуальный редактор для MediaWiki) и хотел его подружить с нашими правами (IntraACL). Для справки — в VisualEditor википеды же тоже прилично извратились — конфигурация там такая — сама вики на PHP, но рядом, чисто для VisualEditor’а, на сервер ставится node.js.

В котором выполняется parsoid, служащий бэкендом к VisualEditor’у. Parsoid — это частично переписанный на js парсер медиавики — полностью не осилили и не осилят никогда, уж больно там говнокода много на него завязано.

И запросы идут через такую жопу: браузер -> PHP -> node.js -> (а дальше нода же хочет получить текст страницы, которую правишь) -> обратно запрос в PHP.

И по дефолту на втором запросе к PHP они его сессионную Cookie ему обратно не передавали. Соответственно, у нас из-за прав доступа отредактировать страницу не удавалось — но зато эта конструкция вообще работала! :)

А когда я включил передачу куки юзера на этом запросе, чтобы нода читала текст страницы с учётом прав — вся эта конструкция стала радостно повисать. Я чуть башку не сломал, а оказывается, это была как раз блокировка сессии. Второй запрос же «вложен» в первый и запускается в той же сессии => 2 ждёт, пока кончится 1, а 1 ждёт, когда закончится 2. Дедлок.

Вот тогда у меня и случилось просветление.))

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

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

Короче: какая-то, с*ка, светлая голова в SemanticMediaWiki впилила для пересчёта какой-то очередной внутренней хрени обработчик очереди. Стандартной медиавиковской очереди — есть у неё в ядре очередь задач, и можно туда свои задачи пихать.

Но так как стандартная обработка заданий идёт в том числе потихоньку в конце каждого запроса, после отдачи страницы юзеру (ну, типа, чтобы работало даже там, где демона не запустишь) — эта, с*ка, светлая голова решила, что это же будет тормозить! И реализовала обработку самого задания через дополнительный запрос с сервера на самого себя, к URLу который фактически обрабатывает задание.

И оно как-то большей частью даже прокатывало… пока пользователь не открывал 2 вкладки одновременно — после чего висло нафиг 2 процесса сервера, а после N повторов висли все доступные процессы сервера и вики переставала отзываться. Причём все такие спокойные — загрузки CPU нет, никто ничем не занят, а вики висит — все в дедлоках.

Сами википеды на свои сессии тоже вроде потом напоролись, но уже после меня (после 1.26) — и то ли в 1.27, то ли в 1.28, вроде, переосмыслили своё поведение.

2016-09-23 Thin RAID5

Блин. А есть в Linux’е что-нибудь такое, чтобы сделать RAID5, но без необходимости полного resync’а? То есть что-то типа thin provision, чтобы блоки под RAID выделялись по запросу. В идеале — чтобы оно при этом поддерживало извращённые схемы расположения, то есть например 3-дисковый (2 данные, 1 чётность) рейд на 4-х дисках 3+3+2+2 тб.

Это кстати очень даже возможно — 3+3+2+2 нарезать на 6.66 тб RAID5! Схема такая: сначала кладём по 2тб на первые 3 диска, остаётся свободных 2*1тб и 1*2тб, кладём на них ещё по 1тб, остаётся 1тб свободный. Дальше забираем 0.33тб из первой группы с 1-го диска и 0.33тб из второй группы со второго диска и перекладываем на свободный 1тб, и на освободившееся место дописываем новую группу 3*0.33тб.

То есть вот так схема выглядит:

111422333
114222333
111222
333214

Вот. ceph так умеет, но он сетевой и распределённый, локально не поюзаешь. ZFS… «thin raid» умеет, но не умеет его расширять — то есть ещё диск не добавишь.

А с LVM, например, нельзя так извратиться?

2016-09-08 Тестирование скорости дешёвого SSD Silicon Power Slim S55 120Гб

Спойлер: Чтение приличное, а вот скорость записи — не очень (устоявшаяся 95 Мб/с).

Отчёт о реальных скоростях данного SSD. Тестировал утилитой fio, под Linux. Глубина очереди везде 128, планировщик noop, слияние запросов в очереди для теста отключено. При снижении глубины очереди производительность сильно проседает; ну, так и не надо её снижать.

  1. Последовательное чтение в идеальном случае (блоками >= 256кб) — 550 Мб/с
  2. Последовательное чтение блоками по 4к — в среднем 190 Мб/с, но прилично колеблется в пределах 170—280 Мб/с
  3. Последовательное чтение блоками по 8к — 370 Мб/с; по 16к — 450 Мб/с; по 32к — 500 Мб/с; по 64к — 530 Мб/с; по 128к — 540 Мб/с. Тут уже все цифры абсолютно стабильны, не колеблются.
  4. Случайное чтение блоками по 4к — 170 Мб/с (~41000 iops), тоже колеблется в пределах 120—220 Мб/с.
  5. Случайное чтение блоками по 8к — 305 Мб/с. По 16к — 340 Мб/с. По 32к — 380 Мб/с. По 64к — 440 Мб/с. По 128к — 510 Мб/с. По 256к — 535 Мб/с (это уже фактически последовательное чтение, а не случайное). Тут скорость опять стабильна, практически без колебаний.
  6. Есть «псевдо-SLC кэш». Последовательная запись первых 2.4 Гб блоками по 4к — 244 Мб/с. Крупными блоками (>= 256к) — 490 Мб/с.
  7. После 2.4 гб запись устаканивается на уровне 95 Мб/с, независимо от размера блока (SLC кэш кончается).
  8. Скорость случайной записи абсолютно идентична скорости последовательной записи.
  9. Скорость записи сохраняется постоянно, в том числе после полной перезаписи всего диска без TRIM.
  10. 30 секунд простоя достаточно, чтобы SLC кэш сбросился и запись вернулась к 490 Мб/с.

Наибольший «физический смысл» имеют случайные чтение/запись блоками 4к (стандартный размер блока ФС как в винде, так и в линуксе), а также последовательное чтение/запись блоками по 16к (так будет, если программа читает по 4к, а драйвер будет объединять соседние запросы), ну либо уже максимальными блоками (если программа копирует данные крупными блоками).

В общем, с чтением всё ок, но огорчает устоявшаяся скорость записи, 95 Мб/с — для SSD мало. Хотя, наверное, за эти деньги ожидать чего-то сильно лучшего и не приходится.

2016-09-07 ФС для флешек

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

Другое дело, что случайная запись с обычными ФС типа ext4 очень медленная, флешки — это не SSD, гигагерцовых контроллеров и гигабайтов оперативки у них внутри нет — потому и Translation Layer внутри тупой, всё, что он обычно умеет — это «открыть» (стереть) и держать «открытыми» 2-3-4 блока стирания (обычно по 2 мб) и поддерживать в них последовательную запись. То есть, случайную запись мелкими блоками флешки не переваривают вовсе — iops на запись при этом обычно ограничивается 3-4 запросами в секунду.

Стандартно это решается лог-структурированными ФС, которые никогда не перезаписывают файлы «на месте», а всегда дописывают новую версию «в конец», одновременно постепенно освобождая место от старых блоков «в начале». То есть такие ФС чем-то похожи на кольцевой буфер :). И такие ФС под linux есть, я их ещё раньше уже тестировал: ubifs, jffs2, yaffs, logfs, nilfs2… фиг кстати знает почему, но в прошлый раз я почему-то остановился на ubifs, хотя она (как и jffs2, и yaffs) предназначена для MTD (голой флеш-памяти, не блочных устройств) и монтировать её одно извращение, и после краша она ещё не восстанавливается потом.

На самом деле из этих лучше брать nilfs2 — вроде самая живая и для блочных устройств подходит. Правда есть у неё как минимум один «нюанс» — на пустой ФС можно получить ошибку «нет свободного места», потому что она защищает (отказывается удалять) часть недавно созданных снапшотов. Время защиты вроде бы задаётся параметром `-o pp` при монтировании, но что-то я даже с pp=1 эту ошибку всё равно время от времени (при интенсивной записи) получал. Да и в общем в стабильность её работы у меня, честно говоря, особой веры нет. Экзотика, в общем.

Ещё отдельный юмор — это самсунговская F2FS (Flash-Friendly FS). Фиг знает, в каком она месте friendly и зачем она вообще создана — случайную запись она не ускоряет вообще.

Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.

И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio, в 8 потоков). Получаем суммарно (чтение+запись):

  • ext4=7.15 iops
  • f2fs=7.38 iops
  • nilfs2=160.8 iops (лог-структурированная ФС)
  • btrfs=128 iops (круто, почти не хуже чем nilfs2)

Короче всё, я на флешках буду btrfs теперь юзать.

2016-08-27 Математическое наблюдение на тему MTBF и AFR

Есть такой параметр, заявляемый производителями жёстких дисков — MTBF (Mean Time Before Failure), среднее время наработки на отказ. Ясно, что он чисто маркетинговый, так как очевидно, что невозможно честно определить его для новой модели. И фигурируют там обычно миллионы часов, самое меньшее 800000 — аж 91 год с гаком.

И вот непонятно — а какого чёрта харды вообще мрут при такой оценке надёжности? :-) ну как же, он 91 год в среднем прожить должен?

Ответ кроется в математике. Есть более осмысленный параметр — AFR (Annualized Failure Rate), вероятность выхода из строя в течение года. По статистике Backblaze (кроме них никто её по ходу не публикует) реальный AFR у дисков Seagate и WD как минимум процентов 5-10, у некоторых «особо надёжных» моделей аж 25-28 %, и даже у дисков HGST не ниже 0,8 % (а в основном 1-1.5 %).

А давайте попробуем по AFR посчитать MTBF? Если предположить, что AFR диска не меняется со временем, то MTBF в годах = 1*(1-AFR) + 2*(1-AFR)² + 3*(1-AFR)³ + … (матожидание числа лет). Разворачиваем формулу дважды в сумму геометрической прогрессии (так как это по сути сумма геометрических прогрессий, начинающихся с 1… 2… 3… и т. п. членов), и получаем MTBF в годах = (1-AFR)/AFR². Можно записать это и наоборот, решив квадратное уравнение, и получить AFR = (-1 + sqrt(1+4*MTBF)) / (2*MTBF).

По этой формуле MTBF 800000 часов = 9,93 % AFR, MTBF 1400000 часов = 7,6 % AFR, MTBF 2000000 часов = 6,4 % AFR. А 1 % AFR соответствует MTBF аж 86724000 часов! То есть, в принципе, MTBF 800000 часов не так уж и много, так как на самом деле он означает, что 10 % дисков выйдет из строя в первый же год :-).

Упс. В вычисления закралась досадная ошибка — правильная формула MTBF в годах = AFR + 1*AFR*(1-AFR) + 2*AFR*(1-AFR)² + 3*AFR*(1-AFR)³ + … = AFR + (1-AFR)/AFR. Соответственно AFR = (MTBF+1 — sqrt((MTBF+1)²-4)) / 2.

И, соответственно, никаких впечатляющих % там не будет — 800000 MTBF = 1.08% AFR, 1400000 MTBF = 0.62% AFR, 2000000 MTBF = 0.44% AFR. Ну ладно, тогда да, MTBF — просто ничего не значащая маркетинговая цифра :). Даже 1.08% — абсолютно нереально реально, современные HGST так и живут. Но когда я это писал, было таки нереально.

UPD: Вторая версия формулы, по-моему, тоже была неправильной, но, что удивительно, численные результаты получились верными. Правильно так:

MTBF = 1*AFR*(1-AFR) + 2*AFR*(1-AFR)^2 + ... = Sum_{i=0..+inf}((1-AFR) * (1-AFR)^i) = (1-AFR) / AFR
1 - AFR = MTBF * AFR  <=>  AFR = 1/(1+MTBF)

По этой формуле MTBF 800000 часов = 1.08% AFR, MTBF 1400000 часов = 0.62% AFR, MTBF 2000000 часов = 0.44% AFR.

А, и ещё картина по идее может зависеть от распределения отказов — интуиция подсказывает, что вряд ли оно равномерное. Но сильно, наверное, это вряд ли повлияет, так как вот тут http://www.cs.cmu.edu/~bianca/fast/ есть статья, из которой видно, что, по-видимому, лет где-то до 5 каждый год вероятность отказа неуклонно возрастает, а потом даже немного снижается.


2016-08-21 Паттерн бэд блоков в ddrescueview

Короче прогнал ddrescue на своём сдохшем Seagate Constellation ES.3 3 тб (ST3000NM0033). Вот такая картина (ddrescueview):

Ddrescue1.png

Если поближе, то вот:

Ddrescue2.png

О чём нам говорит такой паттерн? Судя по всему, об одной полностью сдохшей головке. Если посмотреть на цифры, то становится чётко видно, что картина по всему диску следующая — в начале диска идёт 50мб читаемых, 50мб нечитаемых, потом 600мб читаемых, потом примерно 50мб нечитаемых, 100мб читаемых, 50мб нечитаемых и дальше так и повторяется — 600-50-100-50… 600мб ближе к концу диска (к центру пластин), на самом деле, превращается в ~265мб, но соотношение всё время сохраняется чётко — 12:1:2:1 (где-то 11.8, где-то 12.2, но суть одна).

Блина у этой модели 4, головок 8. Потеряна как раз 1/8 данных. Логично, что это как раз и должно означать мёртвую головку. Единственным непонятным для меня моментом был паттерн — я думал, раз головок 8, хард с них должен читать по порядку — 12345678 12345678 и т. п. Но тогда картина читаемых-нечитаемых областей выглядела бы как 7-1-7-1-7-1…, а не 12-1-2-1-12-1-2-1…, как у меня.

Ответ, оказывается, простой — вместо традиционной схемы диски сейчас применяют также схемы «Cylinder Serpentine», «Surface serpentine» и их комбинации. В моём случае это как раз «Cylinder serpentine»: 12345678 87654321 12345678 87654321…, и плохая тут, видимо, как раз 2-я головка: 1(2)345678876543(2)11(2)345678876543(2)1…

Такой вот получился «RAID 0» из одного диска — сдохла одна головка, а потеряется почти всё, так как все данные дырявые, максимальный размер неповреждённой области — 614 мб.

Интересные ссылки по теме:

2016-07-30 Корпус Aerocool - наедалово

Твою мать! Козлы! https://market.yandex.ru/product/9275336, https://market.yandex.ru/product/9275333 - написано, что безвинтовое крепление HDD, в отзывах кто-то подтверждает — да, безвинтовое крепление, да, удобно.

А там оно не то что безвинтовое! Там и винтового-то не очень! Схема крепления через дикую жопу. Какие салазки, вы о чём! Крепления хардов просто какой-то суперизвращенец придумывал:

  • два 3.5" в самом низу на винтах, вставляются со стороны материнки.
  • один 2.5" плашмя на отведённом месте + с ОДНОЙ стороны крепится винтами.
  • один 2.5" аж вертикально, крепится к панели внутри корпуса 4 винтами.
  • один 3.5" плашмя на отведённом месте под 5.25" отсеками и крепится винтами.
  • и один 3.5" прикручивается к специальной 5.25" панельке-переходнику, к ней же по желанию под хард лепится доп.вентилятор (если докупишь) и этот страшный бутерброд ставится в 5.25" отсек.

И ещё остаётся пара свободных 5.25" отсеков (нафиг они вообще нужны в 21 веке). ЖЕСТЬ.

Повёлся блин на описание товара. Заказал, теперь возвращать буду.

2016-07-21 Опа! В связи с законом о перс данных Seagate гарантии больше нет

За#бцааааа…

Гарантия производителя на диски Seagate Constellation ES.3 — 5 лет, но похоже, что теперь в связи с законом о персональных данных ей невозможно воспользоваться: http://www.seagate.com/ru/ru/support/russia-law/

Типа мы же иностранная компания, гарантийные запросы обрабатываем за рубежом. А они включают персональные данные.)). запретили обрабатывать персональные данные — вот и идите со своей гарантией в жопу в магазин, где покупали. :-))

Это у меня такой хард дуба дал. производство 2013, купил либо в 2013, либо в 2014, гарантия в магазинах обычно года 2-3, но главное чек не могу найти и не помню где брал…

2016-07-21 Helvetica Neue Condensed

Всегда считал, что Helvetica — это тот же Arial, а так как Arial не люблю, считал, что и Helvetica — отстой. Потом, правда, понял, что в мелких размерах Arial выглядит неплохо, но уже было не важно).

А недавно открыл для себя, что Helvetica Neue ещё бывает Condensed и вот это классный шрифт. Правда, в теории платный, но кого ж это волнует на самом деле, он настолько похож на свободный Roboto Condensed, что фактически можно юзать его (хотя субъективно гельветика чуть поаккуратней). Ещё один похожий шрифт — PT Sans Narrow (но он-то точно покривей). Вот все три:

Condensed.png


Посередине Helvetica, сверху Roboto, внизу PT Sans.

2016-06-27 Минутка юмора nodejs

Задача: вытащить часть пути до первой части, содержащей glob-паттерн (glob — это стандартные шаблоны имён файлов: * ? [] {}).

Решение: один регэксп, да? Нееееет!

Для node.js есть целая библиотека glob-parent. Очень содержательная:

var path = require('path');
var isglob = require('is-glob');
 
module.exports = function globParent(str) {
	str += 'a'; // preserves full path in case of trailing path separator
	do {str = path.dirname(str)} while (isglob(str));
	return str;
};

Не, ну наверно там парсинг сложный, да? Давайте посмотрим, как написан is-glob:

var isExtglob = require('is-extglob');
 
module.exports = function isGlob(str) {
  return typeof str === 'string'
    && (/[*!?{}(|)[\]]/.test(str)
     || isExtglob(str));
};

Гм. Ну что ж, может вся хитрость в is-extglob?

module.exports = function isExtglob(str) {
  return typeof str === 'string'
    && /[@?!+*]\(/.test(str);
};

Это весь код этих 3-х библиотек, ну за исключением всяких README и package.json, конечно… которые там в 5 раз больше.

Alice-facepalm.jpg

2016-06-16 ClickHouse

ВАУ! ЖИР!

Яндекс сделал опенсорсную столбцовую СУБД! ClickHouse.

https://github.com/yandex/ClickHouse

https://habrahabr.ru/company/yandex/blog/303282/

2016-03-04 А между прочим, в 5-м Android'е (в ART) запилили именно то, о чём я говорил

А между прочим, в 5-м Android’е, в новом рантайме ART, запилили именно то, о чём я говорил!

А именно — «разделяемые assembly». То есть чтобы можно было писать dalvik-библиотеки, которые не нужно, как jar’ники, загружать заново в каждый java-процесс.

Именно это и сделано в ART (ART — прозрачная замена Dalvik): вместо JIT-компиляции они теперь перешли к AOT, dex’ы теперь компилятся в нативный код, складываются в файлик на диске, а потом из него mmap()ятся — и, соответственно, ведут себя приблизительно как обычные .so’шки, не сжирая память отдельно в каждом процессе. Точно так же это сделано и в .NET — чтобы assembly превратить в разделяемый код, нужно её прекомпилировать.

Зиготу (zygote), правда, всё равно оставили, чтобы держать в общей памяти ещё и преинициализированные данные, и таким образом всё-таки экономить ещё чуть-чуть памяти. Но всё равно молодцы. По сути, это теперь получается, что ART чуть ли не круче самой явы :) вот бы его на десктопе попробовать с java кодом… :)

2016-03-01 Тупняк, но реально Quadro и FirePro - нае..надувательство

Обалдеть, вот дурь-то. Производимые и Nvidia, и AMD «профессиональные» видеокарты (Quadro, FirePro) — тупое искусственное разводилово. Просто в «непрофессиональных» на уровне firmware обрезают часть функционала и производительности в числах двойной точности, а аппаратно они ИДЕНТИЧНЫЕ.

В качестве пруфа можно привести тему на форуме, в которой чувак путём перепайки пары SMD-резисторов смог поменять PCI ID своей GTX690 и она ВНЕЗАПНО превратилась в Quadro K5000: http://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/

Жёсткое нае..дувательство, я бы такое запретил законодательно… запретил бы физически один и тот же продукт продавать по разной цене и под разными названиями. Вполне, по-моему, на мошенничество тянет)

2016-02-19 Уроды на службе FCC

Вашу ж мать. TP-LINK уже внедряет запрет обновления прошивки в соответствии с уродством FCC... http://www.opennet.ru/opennews/art.shtml?num=43907

2015-12-30 Итоги 2015 года

В общем, по итогам 2015 года стало чётко ясно, что всё это не временный маразм и кризис, а вполне осознанно установленный курс:

  • внешнеполитический — на конфронтацию с Западом
  • внутриполитический — на защиту жуликов и подавление оппозиции
  • в интернете — цензурно-запретительный
  • в рубле-баксе — 50р за $ уже видимо не будет никогда, не говоря уже о 35. дай бог на 80-90 не улететь.
  • народного протеста не будет — половина ЗА, половина просто делает вид, что ничего не происходит

Всё это было и в 2014 году, но тогда надежда на скорое выравнивание ситуации ещё была, а теперь, по-видимому, понятно, что это было лишь начало тренда, а ближайшие лет 3-5-10 будет продолжение.

Так что чем НГ ближе, тем что-то мне грустнее…

Вот кстати хорошая статья по теме: http://www.gazeta.ru/column/vladislav_inozemcev/7996685.shtml

...И подчеркну еще раз: ничто из отмеченного не привлекает особого внимания.

Это означает только одно: в отличие от 1998, 2008 или 2014 годов, кризис стал восприниматься в России как нечто обыденное.

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

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

Do you want to try some new features? By joining the beta, you will get access to experimental features, at the risk of encountering bugs and issues.

Ок Нет, спасибо