Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.
Чтобы теоретически определить лучшее физическое место для размещения своего сервера, я объединил общедоступные данные о задержках с собственными журналами доступа к веб-серверу. Я стремлюсь получить грубый, количественный, ответ, основанный на реальном наборе данных.
Определение TTL для некоторых кэшированных данных («time to live» — время существования или длительность хранения) может стать своего рода шарлатанской нумерологией для программистов. Кеширование по TTL даёт корректность в пользу увеличения скорости. Но до какой степени можно отказаться от корректности? Как долго можно показывать где-то неправильное значение, прежде чем пользователь будет сбит с толку? Как скоро такие пользователи заподозрят наличие у себя проблемы и лягут бременем на службы поддержки клиентов? Давайте разбираться.
Хотелось бы поделиться опытом оптимизации данных с целью уменьшения расходов на ресурсы.
В системе рано или поздно встает вопрос об оптимизации хранимых данных, особенно если данные хранятся в оперативной памяти, как это БД Redis.
Как временное решение, можно увеличить RAM тем самым можно выиграть время.
Redis это no-sql база данных, профилировать ее можно с помощью встроенной команды redis-cli --bigkeys, которая покажет кол-во ключей и сколько в среднем занимает каждый ключ.
Объемными данными оказались исторические данные типо sorted sets. У них была ротация 10 дней из приложения.
Проект в продакшене, поэтому оптимизация никак не должна была сказаться на пользователях.
Данные из себя представляли события измененияцены / даты доставки у оффера. Офферов было очень много – порядка 15000 в каждом фиде (прайслисте).
Рассмотрим следующий пример данных события по офферу:
Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.
В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:
journald решает все наши проблемы
документации по нему подозрительно мало (особенно, в сравнении с systemd)
при том, что его поведение более-менее разумно, интуиция о том, как он работает, практически отсутствует и её надо набирать.
Многим, кто работает с MySQL, известно, что команда EXPLAIN используется для оптимизации запросов, получения информации об использованных и возможных индексах. Большинство разработчиков и администраторов СУБД этой информацией и ограничивается. Я же предлагаю изучить команду EXPLAIN максимально подробно.
KubeHelper - это продукт, который упрощает решение многих ежедневных задач связанных с управлением Kubernetes через веб интерфейс. Поиск, анализ, запуск команд, “cron jobs”, репорты, фильтры, git синхронизация и многое другое.
KubeHelper это не ещё одна попытка отобразить Kubernetes API в графическом интерфейсе. Не попытка заменить Lens, официальный Dashboard или другие продукты. Это мой скромный вклад в Kubernetes Open Source сообщество. Проект не имеет какого-то узко специализированного направления и содержит довольно много различных функций которые будут полезны в ежедневной работе с Kubernetes.
Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.
И да, в посте будет математика. Целых две формулы. Я предупредил.
Привет, меня зовут Павел. Я работаю ведущим системным инженером группы внедрения в департаменте вычислительных систем компании STEP LOGIC. В этом посте я поделюсь своими наблюдениями о флеш-системе хранения данных Huawei OceanStor Dorado V6, которую мы тестировали в «полях» в инфраструктуре заказчика.
Если дальше ожидаете увидеть данные по полученным в результате тестирования показателям IOPS, то спешу разочаровать. Немного отойду от привычной схемы и сначала расскажу о результатах проверки дополнительных функций. Это позволит оценить возможности ввода в эксплуатацию и дальнейшего обслуживания глазами (и руками) системного администратора, системного инженера со стороны заказчика.
Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.
Привет, меня зовут Евгений. Я разрабатываю инфраструктуру поиска Яндекс.Маркета. Хочу рассказать, как graceful degradation помогает нам обрабатывать больше запросов, чем физически могут выдержать наши сервера, и что происходит с поиском в Маркете, если один из дата-центров отключается.
Начиналось всё с создания небольшого стенда для тестирования серверов нашей собственной разработки. Но аппетит приходит во время еды, и в итоге мы создали единственную в России и вторую в Европе лабораторию OCP Experience Lab.
В этом году Apple потрясла рынок десктопных процессоров чипом Apple M1 и устройствами на нём. Похожее событие произошло в мире облачных вычислений в прошлом году. AWS выпустили новый тип сервера на собственных ARM процессорах Graviton2. По заявлениям Amazon, соотношение производительности к цене у новых процессоров на 40% выше, чем у аналогов на x86. Ещё одно недавнее обновление - сервера Amazon RDS (облачный сервис, предоставляющий сервера баз данных) на Graviton2. Я запустил несколько бенчмарков и нагрузочный тест реального бэкенд приложения, чтобы проверить настолько ли хороши сервера на ARM процессорах и узнать какие проблемы совместимости могут возникнуть.
