1. Введенние.
2. Zval.
3. Циклические ссылки.
4. Сборщик мусора.
5. Алгоритм работы сборщика мусора.
6. Смотрим глазами.
7. Слабые ссылки.
8. Бонус-трэк: WeakMap.
9. Заключение.
Облачные сервисы — это отлично, но, если ими начинают пользоваться разные команды в компании, вопрос управления затратами превращается в «черный ящик». Когда мы только начинали нашу историю с FinOps, то даже не представляли, насколько эффективнее можно раскрутить историю с арендой облачных мощностей. Но оказалось, что расширение практик управления затратами помогает получить от облаков еще больше отдачи и не допустить необдуманных трат (а то один стартап решил как-то вечером расшифровывать ДНК на арендованных мощностях, а утром закрыл компанию, потому что потратил все деньги). О том, как это было, какие грабли мы собрали по пути, как нам помогла команда ИБ и за счет чего мы теперь экономим до 20% на облачных счетах, читайте под катом.
1. Общие сведения.
2. Увеличиваем потребление памяти вдвое.
3. Увеличиваем потребление памяти втрое.
4. Ещё раз увеличиваем потребление памяти на ровном месте.
5. Заключение.
Что описывается: Apollo-client — популярная библиотека для работы с GraphQL. Библиотека призвана ускорить разработку и оптимизировать приложение.
Задача статьи: Описать возможные решения и проблемы оптимизации приложения в части apollo-client.
Исповедь о том как принес в проект проблему, которую так и не устранил в течение долгого времени.
Осторожно! Статья может вызвать обострение профессиональных заболеваний вплоть до боли ниже поясницы.
По прогнозам MarketsandMarkets, глобальный рынок гиперконвергентных систем к 2025 году достигнет объёма в 17,1 млрд долларов США. Среди факторов, стимулирующих рост рынка гиперконвергентной архитектуры, можно выделить повышенный интерес к облачным вычислениям, виртуализации, стремление сократить расходы на инфраструктуру и упростить управление.
Гиперконвергентной называют программно определяемую инфраструктуру, в которой вычислительные и сетевые ресурсы, а также хранилища составляются из унифицированных компонентов без заранее выделенных ролей. Такая архитектура обеспечивает простоту, скорость и наглядность, а также единообразие вместо дискретности.
В этой статье мы рассмотрим сервер Altos BrainSphere R380 F5, который отлично подходит для использования в качестве унифицированного компонента гиперконвергентной архитектуры.
Рекомендую присмотреться к списку, если ваш проект вырос или планирует рост, написанный на любом интерпретируемом языке (php/ruby/python) на нескольких серверах с обычным стеком (веб-сервер/сервер приложений, субд, redis/memcahed, rabbitmq, ...).
В качестве подопытного для оптимизации был взят PHP backend - все нижеперечисленные приёмы были опробованы и применены. Наш проект почему-то задыхался на казалось бы неплохом железе и к тому же не утилизировал выданные ему аппаратные ресурсы.
В этой статье мы создадим простое приложений на основе MQTT с использованием брокера сообщений EMQX и настроим наблюдение через встроенные механизмы трассировки.
Производители серверов во все времена придумывали всякие нестандартные разъемы для подключения внешних адаптеров, которые называли обобщенно «Mezzanine card». Будучи проприетарными по физическому исполнению, в большинстве случаев они были просто другой распиновкой шины PCI Express. Причиной такого инженерного творчества была необходимость не занимать под адаптеры ценные малочисленные штатные разъемы той же шины, которых дефицит в особенно популярных серверах высотой 1U.
В отличие от десктопных систем малого форм-фактора (все эти Slim,Tiny PC), которые один американский обозреватель едко назвал «Системы, необходимые в условиях низколетающих самолетов», в серверах подобная минимизация высоты корпуса влечет прямую выгоду при размещении их в провайдерских стойках, до 42 штук в один шкаф.
Другая причина - возможность выпускать в этом «нестандартном стандарте» свои адаптеры, которые нечем заменить.
Информация давно стала новой нефтью, поэтому потребности в её обработке растут бешеными темпами. Заинтересованные в преимуществах от владения массивами данных компании запасаются серверными ресурсами и даже строят свои ЦОДы, чтобы не зависеть от доброй воли крупных игроков и не участвовать в трансграничной передаче данных.
Наиболее востребованные сегодня задачи — высокопроизводительные вычисления, машинное обучение и искусственный интеллект, виртуализация и облачные сервисы, — чрезвычайно требовательны к аппаратным ресурсам. Их просто невозможно решить, имея в распоряжении серверы начального или даже среднего уровня.
В этом посте мы расскажем о сервере Altos BrainSphere R360 F5, который подойдёт для самых ресурсоёмких задач. Как, к примеру, насчёт 4 ТБ RAM в 1U корпусе? Но давайте обо всём по порядку.
В этой статье мы расскажем о переносе одного из компонентов монолитного SAAS-сервиса, а именно тестового интернет-магазина, в контейнеры. Статья будет полезна тем, кто только приступил к изучению Docker.
Хорошо, если у вас небольшие (сотни гигабайт) базы, а ночью или в выходные вы можете себе позволить иметь 'maintenance window' и дефрагментировать таблицы. А если нет? В любом случае дефрагментация многих терабайт может занять дни, так что существование maintenance window становится непринципиальным.
Case study: многие терабайты данных, деятельность связанная с процессингом карт (24/7, maintenance window нет в принципе), MSSQL. Разумеется, Enterprise Edition, разумеется AlwaysOn.
Миф: у нас SSD, поэтому дефрагментация нам не нужна. Еще как нужна! Часто в высоко нагруженных системах не делают дефрагментацию, потому что это сложно. В итоге процент фрагментации выходит на уровень почти 100%, и таблицы занимают в два раза больше страниц, чем нужно. В два раза больше места - это в два раза хуже Buffer Cache Hits Ratio. Это в два раза больше размер full backups. Это в два раза дольше full table scans. Это выше CPU (потому что страницы перемещаются с помощью процессора, а не сами по себе).
Каждый из нас сталкивался с необходимостью настройки сложного ПО, интенсивно потребляющего ресурсы компьютера. Как правило, у такого софта довольно объёмная конфигурация, и из-за этого бывает трудно подобрать комбинацию параметров, при которой этот софт демонстрировал бы высокую производительность при минимальной утилизации железа.
Одна из наиболее ресурсоемких категорий софта сегодня — это системы хранения данных. К ним можно отнести как классические СУБД, так и хранилища различного назначения. В корпоративной почтовой системе Mailion мы используем объектное хранилище собственной разработки — Dispersed Object Store (DOS). Mailion поддерживает одновременную работу до миллиона пользователей, и подобный уровень нагрузки выдвигает существенные требования к производительности и экономической эффективности системы.
Под катом рассказываем, как мы искали оптимальную конфигурацию нашего объектного хранилища, и какие уроки извлекли из этого поиска.
Всех приветствую, меня зовут Антон Рябых, работаю в Doubletapp. Вместе с коллегой Данилом Гальпериным мы написали статью про важный этап в процессе обучения нейронных сетей и получения необходимых нам результатов — оптимизацию модели. Зачем нужно оптимизировать модель, если и так все работает? Но как только вы начнете разворачивать модель на устройстве, которое будет ее обрабатывать, перед вами встанет множество проблем.
Более крупные модели занимают больше места для хранения, что затрудняет их распространение. Более крупные модели требуют больше времени для работы и могут потребовать более дорогого оборудования. Это особенно важно, если вы создаете модель для приложения, работающего в реальном времени.
Оптимизация моделей направлена на уменьшение размера моделей при минимизации потерь в точности и производительности.
Методы оптимизации
• Pruning — устранение части параметров нейронной сети.
• Quantization — уменьшение точности обрабатываемых типов данных.
• Knowledge distillation — обновление топологии исходной модели до более эффективной, с уменьшенным количеством параметров и более быстрым выполнением.
• Weight clustering — сокращение количества уникальных параметров в весах модели.
• OpenVino, TensorRT — фреймворки, с помощью которых можно оптимизировать модели.
От запуска ознакомительной версии нового улучшенного поиска кода год назад до публичной беты, которую мы выпустили на GitHub Universe в прошлом ноябре, появилась масса инноваций и резких изменений в некоторых основных продуктах GitHub, затрагивающих то, как мы, разработчики, осознаём, читаем код и ориентируемся в нем.
Нам часто задают вопрос о новом поиске по коду: «Как он работает?». В дополнение к моей лекции на GitHub Universe, я в общих чертах отвечу на этот вопрос, а также немного расскажу о системной архитектуре и технических основах данного продукта.
Так как же он работает? Мы создали собственный поисковый движок с нуля на Rust специально для поиска по коду. Наш поисковый движок называется «Blackbird», но прежде чем я стану описывать как он работает, думаю, что нужно понять наши предпосылки. На первый взгляд, создание поискового движка с нуля выглядит спорно. Зачем это делать? Разве уже нет большого количества существующих решений с открытым исходным кодом?
В статье я расскажу, как можно (при необходимости) быстро и дешево собрать кластер Beowulf на основе домашних компьютеров. Выполню я это с помощью компьютеров находящихся в аудитории университета, используя существующую локальную сеть. Используемые программные инструменты: средства численного моделирования механики сплошных сред OpenFOAM, сетевого протокола прикладного уровня SSH и распределенного протокола файловой системы NFS. Все выполнялось под управлением операционной системы ubuntu 20.04.
