Мы продолжаем наш рассказ о причинах повышенного потребления памяти в языке Go. В предыдущей статье мы детально разобрали ошибки бизнес-логики приложения, которые могут привести к утечкам памяти. Сегодня же сосредоточимся на особенностях рантайма языка Go.
Я часто заморачиваюсь на тему минимизации размера своих GUI приложений. Прошлая моя статья была про Nuklear. Но сейчас захотелось более современных технологий. Чтоб HTML5, CSS3 и PHP. Чтоб приложение ни от чего не зависело, т.е. построено по принципу "всё включено". И чтоб конечный размер приложения не превысил 2 МБ. Получится ли?
В Linux я часто пользуюсь утилитой df. Мне её очень не хватает в Windows, а искать аналоги лень. Так что было сделано волевое решение сделать свою, на РНР 5, с бутстрапом и JQuery.
Практика CI/CD широко распространена в современном мире и представить ручной деплой у FAANG с их бесчисленными ежедневными изменениями просто невозможно. То же будет справедливо и для продуктовых компаний: десятки ручных деплоев в день вытянуть можно, но это потребует колоссальных ресурсов.
Освоить эту практику можно дома, в среде, где что-то сломать не страшно, ведь всегда можно начать все с самого начала. В этом гайде рассмотрим как развернуть и настроить Jenkins в Docker, как создать агентов для сборки, а еще запушим образ в приватный Nexus.
За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.
Всякий раз дискуссия выходит к одним и тем же ответам:
Bash-скрипты — эффективное решение для автоматизации рутинных задач, но не всегда самое простое. Объемные сценарии характеризуются низкой производительностью и сложны для чтения. В этой статье мы рассмотрим, как оптимизировать работу, упростить с помощью утилит sed и awk и не совершать очевидных ошибок в написании скриптов.
Можно любить Go за многое: за простоту и строгость, за горутины и каналы, за реализацию параллельного и асинхронного программирования, за продвинутый планировщик, за аллокатор с большим количеством оптимизаций, за высокую производительность.
Но, по сообщениям некоторых пользователей, у программ, написанных на Go, течёт память. Issue-трекер языка Go на github по запросам «high memory usage», «memory leak», «out of memory» выдаёт сотни и тысячи тикетов. А в самом популярном вопросе на stackoverflow по словосочетанию «golang memory» автор пытается разобраться, почему потребление оперативной памяти в рантайме в 4 раза превышает количество реально сделанных аллокаций. Обращения, в которых люди рапортуют о перерасходе оперативной памяти в Go, стали массовым явлением.
Что же это — утечки памяти, вызванные программистскими ошибками, или ожидаемое поведение рантайма языка? Мы попытаемся разобраться в причинах этого явления и сформулировать общие рекомендации, которые помогут в отладке проблем с потреблением памяти.
В прошлый раз мы рассмотрели, что такое синхронное программирование, и с какими проблемами с ним сталкивается разработчик. На примере простого сервера с блокирующими сокетами мы увидели, что в синхронно выполняющейся программе все инструкции выполняются строго по очереди, и если встречается системный вызов ввода-вывода, то он может полностью остановить выполнение программы на довольно продолжительное время — пока не завершится. Весь этот период процессор простаивает в ожидании, хотя мог бы выполнять другие задачи, которых накапливается немало. В результате сервер одновременно может обрабатывать только одно подключение. Чтобы перейти ко второму, предыдущее должно быть закрыто.
Решить проблему многозадачности можно стандартными средствами вытесняющей многозадачности: процессами или потоками. Но тут разработчик сталкивается с достаточно серьезными трудностями. Процессы требуют дополнительных ресурсов на свое обслуживание, а потому невыгодны. А потоки влекут за собой множество трудноотлавливаемых и сложновоспроизводимых багов, из-за чего требуется долгая и кропотливая дополнительная работа по синхронизации потоков. В результате мы становимся перед выбором: или дополнительные расходы на железо, или дополнительные расходы на программистов.
Но, к счастью, существует и третий вариант — кооперативная многозадачность с помощью системного вызова select и его аналогов (poll, epoll и других). Он позволяет мультеплексировать несколько задач в одном потоке выполнения и в сущности является обычной синхронной программой. А потому никаких дополнительных трат процессорного времени и времени разработчиков не требуется.
Во второй части нашего похода за сокетами мы от теоретического их рассмотрения перейдем к практике. Мы разберемся, чем плохи блокирующие сокеты, как решить проблему одновременной обработки соединений с помощью процессов, и почему потоки использовать лучше. Попутно разберемся с проблемами синхронизации потоков и зачем нужен GIL. В конце нам должно стать понятно, что с процессами и потоками нужно уметь работать, но никогда не стоит их использовать в реальных проектах, а применять вместо них системный вызов select и асинхронность.
Дабы исчерпать до дна тему сокетов в Python я решил изучить все возможные способы их использования в данном языке. Чтобы всех их можно было испытать и попробовать на зуб, были созданы 19 версий простого эхо-сервера: от примитивного использования класса socket до asyncio. Блокирующие и неблокирующие сокеты, процессы и потоки, select'ы и selector'ы, коллбеки и сопрограммы — все эти темы расположены в эволюционном порядке, чтобы один пример плавно перетекал в другой.
Отдельно разобрано появление асинхронности в Python. На примерах детально показано, как и зачем появились итераторы, из них — генераторы, сопрограммы. Ближе к концу построен учебный макет библиотеки asyncio с минимально необходимым кодом, чтобы любой (даже такой, как я) смог разобраться, как на самом деле устроена асинхронность, как там все внутри работает.
Пишу подробно, чтобы случайно чего не пропустить. Поэтому понятно должно быть всем.
Одной из проблем развития бортовых систем для автомобиля является создание качественного переносимого программного обеспечения, которое бы работало на бортовых системах разных автопроизводителей и могло быть скомпилировано под разные аппаратные и программные архитектуры. Несмотря на очевидную актуальность, задача осложнялась прежде всего тем, что большинство автопроизводителей предпочитало создавать собственные проприетарные операционные системы, что затрудняло создание переносимого программного обеспечения. Ситуация изменилась со стартом проекта Automotive Grade Linux (AGL), поддерживаемыми крупными компаниями такими как Toyota, Mazda, Suzuki, Ford и Mercedes Benz и производителями медиасистем (например, Panasonic). И в планах развития проекта Flutter на 2022 год обозначено развитие поддержки AGL как целевой платформы для приложений. В этой статье мы рассмотрим основные идеи создания переносимых приложений для AGL на Flutter.
OOM Killer — защитный механизм ядра Linux, призванный решать проблемы с нехваткой памяти. При исчерпании доступной памяти он принудительно «убивает» наиболее подходящий по приоритетам процесс, отправляя ему сигнал KILL. Сообщение об этом отображается в /var/log/syslog (Debian/Ubuntu) или /var/log/messages (Centos/Rhel).
Иногда OOM Killer может затрагивать важные процессы, нарушая работу проекта. Как исправить это, узнали у Сергея Юдина, инженера Southbridge. Ниже подробный кейс с примерами кода.
Не так давно состоялся релиз PureBasic версии 6.00, в котором среди прочего добавлена поддержка ARM процессоров. В списке поддерживаемых платформ присутствует Raspberry PI, но вероятно должны поддерживаться и другие похожие одноплатные компьютеры. Мною была проверена работа на большинстве моделей Raspberry PI включая самую простую - Zero и топовую на текущий момент - 4B. На всех была установлена Raspberry Pi OS April 4th 2022. Как и ожидалось, PureBasic запустился и нормально работал на всех тестовых Raspberry PI.
Начало
Все началось с идеи, как и всегда. Кто-то при мне упомянул про удаленный доступ без покупки белого IP и я вспомнил, как хотел осуществить подобное когда-то, но руки так и не дошли.
Но, благодаря этому, я, так же, вспомнил, как когда-то давно, я наткнулся на статью про ngrok. Ссылки на нее, к сожалению, я не сохранил и, благополучно забыл. Но теперь, с пылающей идеей в голове, я устремился на поиски самого ценного ресурса, для осуществления задуманного — информации.
Имею парочку VDSок для различных нужд (почта, веб-сервер, хранилка и т.п.) так вот, возникла необходимость скрывать порты (22, 443 и т.п.) от посторонних глаз. Немного подумав, а идея уже не новая, решил написать простенький, так сказать, ICMP knocker, то есть открытие портов по пингу. Но пингу не простому, а с определенным размером пакета. Пример для линукс:
ping -s 999 -c1 mysrv.com
Где -s - размер отправляемого сообщения, -с количество.
Любой системный администратор сталкивался или столкнется с ситуацией, когда стандартных возможностей распределения прав в Linux недостаточно для выполнения задачи. Но не всегда лучшим решением станет подключение ACL.
Эта статья поможет определиться действительно ли проекту требуется гибкость на уровне пакета ACL и какие проблемы могут возникнуть при его использовании.
Итак, знакомьтесь ближе с теоретической и практической составляющими утилиты.
Распространение приложений в линуксе - это боль. Причем в наше время цикл обновлений приложений все уменьшается и эта боль чувствуется все сильнее. В связи с этим появляются технологии вроде snap, flatpak, которые декларируют решение этих проблем. Некоторые дистрибутивы (я смотрю на тебя, Ubuntu) даже начинают довольно агрессивную политику по их внедрению. Однако, несмотря на то, что про сами эти технологии много говорят (и ещё больше жалуются), про то, как они работают написано довольно мало. Попробуем исправить это.
Disclaimer: в этой статье я не буду давать каких-то оценок, пытаться говорить что лучше. Только как это работает. Я предполагаю, что читатель знает что такое контейнеризация и как это примерно работает.
