Pull to refresh
27
0.6
Дмитрий Симаков @BasilioCat

User

Send message
Я правильно понимаю, что вы тестируете 4k блоками ZFS с дефолтным recordsize=128k? В начале статьи упомянуты виртуальные машины, но не упомянуты методы виртуализации, и как диски машин хранятся на файловой системе. Без оглядки на виртуализацию (внутри виртуалок обычно работают реальные задачи) для MySQL/InnoDB размер recordsize должен равнятся 16k (по умолчанию), для PostgreSQL — 8k. Если у вас предполагаемая нагрузка не БД, а отдача файлов, то тестировать надо вообще блоками по 128k.
Ну и ARC для zfs выключается zfs set primarycache=metadata, если нужно оценить его влияние на скорость чтения. Ну и 10Гб — весьма странный объем данных для тестирования, сейчас памяти в серверах в разы больше, для устранения влияния кэшей размер должен быть больше объема памяти на порядок.
Если выполните TRUNCATE TABLE — то уменьшится
У меня сложилось впечатление, что в Sphinx отсутствие проверок на ошибочные данные было/стало скорее фичёй. Это следует из оборачивания проверок в assert() — в случае реально возникающей проблемы (а не гипотетической), запускается дебажная версия, и баг фиксится, а в продакшене ресурсы процессора на бесполезные проверки не расходуются. Я, правда, столкнулся с ситуацией, когда дебажная версия всегда падает на определенном запросе к определенному набору данных, а обычная — работает. Да и не выставишь дебажную версию в продакшен — она не справляется с нагрузкой (к вопросу об оверхеде), а некоторые проблемы вылезают только там (видмо есть race condition). Еще можно отметить трудноуловимые глюки с тредами под FreeBSD, из-за чего пришлось перенести его на линукс, где эта скульптура из подпорок находится в более сбалансированном состоянии ;) Но в целом альтернатив Sphinx по производительности нет.
И еще мне кажется, это часть большой истории о том, как в перспективный стартап пришли венчурные инвесторы, жаждущие тысяч процентов роста, а основатели и управленцы не были готовы к взрывному росту. Набрали кучу разработчков, но основатель сопротивлялся, а менеджмент с ним не справился. В результате недовольные инвесторы сменили менеджмент и дали новой команде возможность приступить к полному переписыванию всего проекта с нуля.
«Капитализм!» (с) к/ф Красная Жара
В оригинальной статье как-то вскользь, но отмечено, что команду управленцев уволили первыми.
His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first.
Ну а то, что акцент в статье сделан на личности Гения, а не на управленческих просчетах, можно списать не на предвзятость автора, а на то, что это было первопричиной проблем. Возможно, Гений был основателем стартапа, но не смог доверить развивать свое детище другим разработчикам
Не совсем ясно, зачем нужны дополнительные точки отказа, у клиента могут быть для этого какие-то свои причины, а может быть просто непонимание этого. Может пропасть связанность между VPS и ДЦ клиента, может отвалиться туннель tinc в ДЦ клиента. Обычно стараются терминировать VPN как можно ближе к оборудованию, к которому будет предоставлен доступ.
«Мы засунули твой VPN в VPN, чтобы… ». Не совсем понятна причина разнесения узлов с OpenVPN по каким-то VPS, при том, что «сервис клиента», к которому нужно получать доступ, находится в другом ДЦ/офисе, с одним или несколькими каналами. В это самое место и надо ставить OpenVPN. Если ДЦ несколько, с разными блоками адресов (но предположительно L2 VPN между ними), то ставить в каждый ДЦ OpenVPN.
Выдавать адреса ДНСом с TTL 0 — ну в принципе не самая плохая затея, но неплохо бы проверять доступность узлов, и выкидывать их при авариях. Но все равно будут перерывы в доступности из-за кэширования ДНС записей.
В Microsoft во времена Балмера сотрудникам запрещалось крайне не рекомендовалось носить iPhone, и использовать опенсорсный софт. Балмер обозвал Линукс раком, и открытые лиценции (типа GNU) — вирусными, заражающими тех кто к ним прикасается. Так что в Майкрософт — вполне себе религия, по крайней мере была раньше.
В первом же примере сравнивается токен, также это может быть и идентификатор сессии. Угнать чужую сессию — это, конечно, не пароль узнать, но не менее эффективно в некоторых случаях
Jail во FreeBSD был в то время небольшим патчем сетевой подсистемы для функционала chroot, а chroot существовал с незапамятным времен. В то время в соляре уже был менеджер ресурсов (память, CPU) для приложений, чего в джейлах нет до сих пор. Конечно, какие-то идеи они позаимствовали из джейла, какие-то — из эмулятора (сисколлов) линукса
Да, IBMовский DTLA — инженерный шедевр своего времени
Больничные по ТК оплачивает государство (фонд соц страхования) и, скажем так, далеко не в полном объеме. Компании от них ущерб разве что в нехватке рабочих рук и срыве сроков
Надо отдать должное NetApp — у них получился действительно инженерный шедевр, от железа до метрик. Вот только стоимость их решений доступна лишь очень жирным котам. Революционность ZFS в том, что Sun взяли годные идеи NetApp, и переписали их, избегая запатентованных технологий, и открыли исходники. Как-то давно примерно так поступил Торвальдс и GNU.
Так что скажем спасибо IBM за многомилионные мейнфреймы, благодаря которым у каждого есть дешевые компьютеры, скажем спасибо NetApp, что их разработки, окупившись в энтерпрайзе, пошли «в народ», и скажем «спасибо» Ораклу, похоронившему дальнейшую разработку ZFS, благодаря чему мы застряли в прошлом десятилетии с файловыми системами.

P.S.: Снапшоты при помощи систем виртуализации для файлового хранилища — это как-то странно. У решений поверх стандартных файловых систем они дадут значительно больший оверхед, у VMWare они интегрированы с файловой системой (=тот же подход, что у wafl/zfs)
Пин-код от карты, отжатой мускуклистыми молодцами, можно попытаться не сказать, а вот не показать лицо банкомату — несколько сложнее. Или Сбербанк будет распознавать эмоции?
Удаление (да и вообще модификация) записей через LIMIT в случае statement-based репликации — не самая хорошая идея. Лучше уж использовать диапазон значений первичного ключа (id >= 5000 AND id < 10000).
Также, в отдельных случаях может быстрее оказаться выбрать оставляемые записи в новую таблицу, на старую сделать truncate, и залить данные обратно. Или просто удалить таблицу, если в нее не ведется запись, а новую переименовать
Ну и конечно, можно таблицы партицировать, в том числе и по времени, и удалять ненужные партиции целиком.
Такие опции будут выдавать Warning при подключении, если не указать -o LogLevel=ERROR. Ну и конечно, их можно не указывать каждый раз, а засунуть в конфиг — ~/.ssh/config:
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
LogLevel=ERROR

Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
Вернуть деньги можно только тому, кто их перечислил. И судя по плате за SMS уведомления это были вполне реальные люди
судя по статье, это были реальные платежные операции из копии продакшен-базы, которые в результате «обезличивания», (а вернее чистки части данных с продакшена), потеряли связь с заказами. А поскольку транзакции и реляционная целостность в современном мире считается устаревшим подходом, для приведения базы в порядок был специальный сервис, отменяющий платежные операции, не привязанные к заказам. Интересно, почему на продакшене нельзя было делать этого вручную, или может даже исправить причину появления таких операций?
На мой взгляд, идея не самя удачная — WAL логи не слишком хорошо подходят для извлечения из них запросов, это лог изменения данных на диске. Из самих WAL файлов (без наличия реплики с реплицированной базой) эту информацию извлечь невозможно.
Если серверов — десятки, то лучше мониторить количество логических дисков с статусом отличным от optimal, и на него повесить триггер. Читать текст SMART в заббиксе — странная идея, если есть реальная необходимость в ранних предупреждениях, то надо мониторить конкретные параметры. Но вообще сбой одного диска — вполне нормальная ситуация для RAIDа, зачем слушать подземный стук, когда проще заменить диск после выхода из строя?

Information

Rating
1,491-st
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity