Что такое tray в linux

Обновлено: 04.07.2024

На HighLoad++ Пётр Зайцев (Percona) сделал обзор доступной инфраструктуры для трейсинга в Linux и рассказал о bpfTrace, который (как видно из названия) дает много преимуществ. Мы сделали текстовую версию доклада, чтобы вам было удобно пересмотреть детали и дополнительные материалы всегда были под рукой.

Инструментацию можно разделить на два больших блока:

Статическая, когда сбор информации зашит в код: запись логов, счетчиков, времени и т.д.
Динамическая, когда код не инструментируется сам по себе, но есть возможность сделать это, когда понадобится.

Tracing — события генерируются, если сработал определенный код.
Sampling — статус системы проверяется, например, 100 раз в секунду и по нему определяется, что в ней происходит.

Но слишком много таких счётчиков не вставишь, всё на свете ими не покроешь. Поэтому бывает полезна динамическая инструментация, которая позволяет смотреть именно то, что нужно. Например, если есть какие-то проблемы с TCP/IP стеком, то можно идти очень глубоко и инструментировать конкретные детали.

DTrace

DTrace — один из первых известных фреймворков для динамического трейсинга, созданный компанией Sun Microsystems. Его начали делать еще в 2001 году, и впервые он вышел в Solaris 10 в 2005 году. Подход оказался весьма популярным и в дальнейшем вошел во многие другие дистрибутивы.

Интересно, что DTrace позволяет инструментировать как kernel space, так и user space. Можно ставить трейсы на любые вызовы функции и специально инструментировать программы: ввести специальные DTrace tracepoints, которые для пользователей могут быть более понятны, чем служебные названия функций.

Особенно важно это было для Solaris, потому что это не открытая операционная система. Не было возможности просто посмотреть в код и понять, что tracepoint нужно поставить на такую-то функцию, как сейчас можно сделать в новом открытом программном обеспечении Linux.

Одна из уникальных, особенно на тот момент, особенностей DTrace в том, что пока трейсинг не включен, он ничего не стоит. Он работает таким образом, что просто заменяет некоторые CPU-инструкции на вызов DTrace, который при возврате эти инструкции выполняет.

В DTrace инструментация записывается на специальном языке D, похожим на C и Awk.

В дальнейшем DTrace появился практически везде, кроме Linux: в MacOS в 2007, во FreeBSD в 2008, в NetBSD в 2010. Oracle в 2011 включил DTrace в Oracle Unbreakable Linux. Но Oracle Linux используют мало людей, а в основной Linux DTrace так и не вошел.

Интересно, что в 2017 году Oracle наконец лицензировал DTrace под GPLv2, что в принципе сделало возможным включение его в mainline Linux без лицензионных сложностей, но было уже слишком поздно. На тот момент в Linux был хороший BPF, который в основном и использовался для стандартизации.

DTrace даже собираются включить в Windows, сейчас он доступен в некоторых тестовых версиях.

Трейсинг в Linux

Что же есть в Linux вместо DTrace? На самом деле в Linux в лучшем (или худшем) проявлении духа open source есть много всего, куча разных tracing frameworks накопилась за это время. Поэтому разобраться, что там к чему, не так просто.

Если вы хотите познакомиться с этим многообразием и вам интересна история, посмотрите статью с картинками и подробным описанием подходов для трейсинга в Linux.

Если говорить про инфраструктуру для трейсинга в Linux в общем, можно выделить три ее уровня:

Интерфейс для инструментации ядра: Kprobe, Uprobe, Dtrace probe и т.д.
«Программа», работающая с этим интерфейсом. События, создаваемые probe, могут происходить миллионы раз в секунду, записывать их все в файл или просто гнать в user space обычно слишком дорого. Для обработки таких событий есть разные подходы: буферизировать в ядре, чтобы потом читать из user space, использовать Kernel Module, чтобы их как-то обрабатывать, и eBPF.
Фронтенд-инструменты, чтобы работать с данными, полученными на предыдущих уровнях: Perf, SystemTap, SysDig, BCC и т.д. bpfTtrace на самом деле один из так фреймворков, если разобраться, что к чему.

eBPF — новый стандарт Linux

Со всеми этими фреймворками в последние годы eBPF становится стандартом в Linux. Это более продвинутый, весьма гибкий и эффективный инструмент, который позволяет практически всё.

Что же такое eBPF и откуда он взялся? На самом деле, eBPF — это Extended Berkeley Packet Filter, а BPF был разработан в 1992 году как виртуальная машина для эффективной фильтрации пакетов файрволлом. Никакого отношения к мониторингу, наблюдаемости, трейсингу он изначально не имел.

В более современных версиях eBPF был расширен (отсюда слово extended), как общий фреймворк для обработки событий. Текущие версии интегрированы с JIT-компилятором для большей эффективности.

Отличия eBPF от классического BPF:

Сейчас люди чаще всего забывают, что был старый BPF, и называют eBPF просто BPF. В большинстве современных выражений eBPF и BPF — это одно и то же. Поэтому же и инструмент называется bpfTrace, а не eBpfTrace.

eBPF включен в mainline Linux начиная с 2014 года и постепенно входит в многий инструментарий около Linux, в том числе Perf, SystemTap, SysDig. Происходит стандартизация.

Интересно, что по-прежнему идет разработка. Современные ядра поддерживают eBPF все лучше и лучше.

Посмотреть, что в каких современных версиях ядра появилось, можно здесь.

Программы eBPF

Итак, что такое eBPF и чем он интересен?

eBPF — это программа в своем специальном байт-коде, которая включается непосредственно в ядро и выполняет обработку трейс-эвентов. Причем то, что она сделана в специальном байт-коде, позволяет ядру провести определенную верификацию, что код достаточно безопасный. Например, проверить, что в нём не используются циклы, потому что цикл в critical-секции в ядре может повесить всю систему.

Но полностью обезопаситься это не позволяет. Например, если написать очень сложную eBPF-программу, всунуть ее в эвент в ядре, который происходит 10 млн раз в секунду, то все может очень сильно затормозиться. Но при этом eBPF куда более безопасен, чем старый подход, когда просто какие-то Kernel Modules вставлялись через insmod, и в этих модулях могло быть все что угодно. Если кто-то допустил ошибку, или просто из-за бинарной несовместимости все ядро могло упасть.

eBPF-код можно скомпилировать LLVM Clang, то есть по большому счету использовать подмножество C для создания eBPF-программ, что, конечно, достаточно сложно. И важно, что компиляция зависит от ядра: используются хэдеры, чтобы понимать, какие структуры и для чего используются и т.д. Это не очень удобно в том плане, что всегда поставляются либо какие-то модули, связанные с конкретным ядром, либо нужно перекомпилировать.

Пользователь создает eBPF-программу. Дальше ядро со своей стороны ее проверяет и загружает. После этого eBPF может подключиться к разным инструментам для трейсов, обрабатывать информацию, сохранять ее в maps (структуру данных для временного хранения). Потом user program может читать статистику, получать perf-эвенты и т.д.

Здесь показано, какие функции eBPF в каких версиях ядрах Linux есть.

Видно, что покрываются практически все подсистемы ядра Linux, плюс есть хорошая интеграция с hardware-данными, у eBPF есть доступ ко всяким cache miss или branch miss prediction и т.д.

Если вам интересен eBPF, обратите внимание на проект IO Visor, в нём собрано большинство инструментов. Компания IO Visor занимается их разработкой, у них вы найдете последние версии и очень хорошую документацию. В дистрибутивах Linux появляется все больше и больше eBPF-инструментов, поэтому я бы рекомендовал всегда использовать последние доступные версии.

Производительность eBPF

По производительности eBPF достаточно эффективный. Чтобы понять, насколько и есть ли overhead, можно добавить probe, который дергается несколько раз в секунду, и проверить, сколько требуется времени на его выполнение.

Ребята из Cloudflare сделали бенчмарк. Простой eBPF probe занимал у них около 100 нс, более сложный — 300 нс. Это означает, что даже сложный probe может вызываться на одном ядре около 3 млн раз в секунду. Если probe дергается 100 тысяч или миллион раз в секунду на многоядерном процессоре, то это не слишком скажется на производительности.

Фронтенд для eBPF

Если вы интересуетесь eBPF и темой Observability вообще, то наверняка слышали о Брендане Грегге (Brendan Gregg). Он много об этом пишет и рассказывает и сделал такую красивую картинку, на которой представлены инструменты для eBPF.

Здесь видно, что, например, можно использовать Raw BPF — просто писать байт-код — это даст полный набор возможностей, но работать с этим будет очень тяжело. Raw BPF это примерно как писать веб-приложение на ассемблере — в принципе можно, но без необходимости делать этого не стоит.

Интересно, что bpfTrace, с одной стороны, по возможностям позволяет получить практически всё, что и BCC, и сырой BPF, но при этом значительно проще в использовании.

На мой взгляд, наиболее полезны два инструмента:

BCC. Несмотря на то, что по схеме Грегга BCC сложный, он включает в себя множество готовых функций, которые можно просто запустить из командной строки.
BpfTrace. Позволяет достаточно просто писать свой инструментарий или же использовать готовые решения.

DTrace vs bpfTrace

В общем и целом DTrace и bpfTrace используется для одного и того же.

Разница в том, что в BPF-экосистеме есть еще и BCC, который можно использовать для сложных инструментов. В DTrace эквивалента BCC нет, поэтому, чтобы делать сложный инструментарий, обычно используют связку Shell + DTrace.

Когда создавали bpfTrace, не было задачи полностью эмулировать DTrace. То есть нельзя взять DTrace-скрипт и запустить его на bpfTrace. Но в этом и нет особого смысла, потому что в инструментарии нижнего уровня логика достаточно простая. Обычно важнее понять, к каким tracepoints нужно подсоединиться, а названия системных вызовов и то, что они непосредственно делают на низком уровне, отличаются в Linux, Solaris, FreeBSD. Именно в этом возникает разница.

При этом bpfTrace сделан через 15 лет после DTrace. В нём есть некоторые дополнительные возможности, которых в DTrace нет. Например, он может делать стек-трейсы.

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

Скрипты DTrace и bpfTrace близки по объему кода и похожи по сложности и возможностям языка.

bpfTrace

Посмотрим подробнее, что есть в bpfTrace, как его можно использовать и что для этого нужно.

Требования к Linux для использования bpfTrace:

Чтобы использовать все фичи, нужна версия, как минимум, 4.9. BpfTrace позволяет делать очень много разных probes, начиная с uprobe для инструментирования вызова функции в user-приложении, kernel-probes и т.д.

Интересно, что для пользовательской функции uprobe есть эквивалент uretprobe. Для kernel то же самое — есть kprobe и kretprobe. Это означает, что на самом деле в трейсинг-фреймворке можно генерировать события по вызову функции и по завершению этой функции — это часто используется для тайминга. Или можно анализировать значения, которые функция вернула, и группировать их по параметрам, с которыми функция была вызвана. Если ловить и вызов функции, и возврат из нее, можно делать много классных вещей.

Внутри bpfTrace работает так: пишем bpf-программу, которая парсится, конвертируется в C, потом обрабатывается через Clang, который генерирует bpf-байт-код, после этого программа загружается.

Процесс достаточно тяжелый, поэтому есть ограничения. На мощных серверах bpfTrace работает хорошо. Но тащить Clang на маленький embedded-девайс, чтобы разобраться, что там происходит, не лучшая идея. Для этого подойдет Ply. У него, конечно, нет всех возможностей bpfTrace, но он генерирует байт-код напрямую.

Поддержка в Linux

Стабильная версия bpfTrace вышла около года назад, поэтому в старых дистрибутивах Linux его нет. Лучше всего брать пакеты или компилировать последнюю версию, которую распространяет IO Visor.

Интересно, что в последнем Ubuntu LTS 18.04 нет bpfTrace, но его можно поставить с помощью snap-пакета. С одной стороны это удобно, но с другой стороны из-за того, как сделаны и изолируются snap-пакеты, будут работать не все функции. Для kernel-трейсинга пакет со snap работает хорошо, для user-трейсинга — может работать неправильно.

Пример трейсинга процесса

Рассмотрим простейший пример, который позволяет получить статистику IO-запросов:

Здесь мы подключаемся к функции vfs_read , причем как kretprobe, так и kprobe. Дальше для каждого thread ID (tid), то есть для каждого запроса отслеживаем начало и окончание его выполнения. Данные можно сгруппировать не только по совокупности всей системы, но и по разным процессам. Ниже вывод по IO для MySQL.

Видно классическое бимодальное распределение ввода/вывода. Большое число быстрых запросов — это данные, которые читаются из кэша. Второй пик — чтение данных с диска, где latency значительно выше.

Общий концепт языка достаточно простой.

Синтаксис: выбираем probe для подсоединения probe[,probe. ] /filter/ < action >.
Filter: указываем фильтр, например, только данные по данному процессу данного Pid.
Action: мини-программа, которая конвертируется непосредственно в bpf-программу и выполняется при вызове bpfTrace.

BpfTrace Tools

В bpfTrace тоже есть набор инструментов. Многие достаточно простые инструменты на BCC сейчас реализуются на bpfTrace.

Коллекция пока небольшая, но там есть кое-что, чего нет в BCC. Например, killsnoop позволяет отслеживать сигналы, вызванные kill().

Если интересно посмотреть bpf-код, то в bpfTrace можно через -v посмотреть сгенерированный байт-код. Это полезно, если хотите понять, тяжелый probe или не очень. Посмотрев код и просто прикинув его размер (одна страница или две), можно понять, насколько он сложный.

Пример трейсинга MySQL

Покажу на примере MySQL, как это работает. В MySQL есть функция dispatch_command , в которой происходят все выполнения запросов MySQL.

Я хотел просто подсоединить uprobe, чтобы распечатать текст запросов, которые приходят к MySQL — примитивная задача. Получил проблему — говорит, что нет такого файла. Как нет, когда вот он:

Это как раз сюрпризы со snap. Если ставить через snap, то могут быть проблемы трейсинга на уровне приложений.

Тогда поставил через apt-версию, более новую Ubuntu, запустил снова:

«Нет такого символа», — как нет?! Смотрю через nm , есть такой символ или нет:

Такой символ есть, но поскольку MySQL скомпилирован из C++, там используется mangling. На самом деле настоящее имя функции, которое используется в этой команде, такое: _Z16dispatch_command19enum_server_commandP3THDPcjbb . Если именно его использовать в функции, то можно подключиться и получить результат. В perf-экосистеме многие инструменты делают unmangling автоматом, а bpfTrace пока не умеет.

Еще обратите внимание на флаг -D для nm . Он важен, потому что MySQL, а сейчас и многие другие пакеты, поставляются без динамических символов (debug symbols) — они идут в других пакетах. Если хочется использовать эти символы, нужен флаг -D , иначе nm их не увидит.

Хорошая новость номер раз: на РИТ++ 25–26 мая Пётр Зайцев расскажет о технологиях и тенденциях на рынке баз данных, которые изменят бизнес через год. Это отличная возможность узнать, какие конкретные решения подойдут в разных ситуациях, от человека с невероятной экспертизой в области БД и оптимизации их производительности.

Хорошая новость номер два: РИТ++ Online стал намного доступнее. Билет для физлиц сейчас стоит всего 5 900 и позволяет разобраться в тенденциях не только БД, но и многих других актуальных технологий, и подробно познакомиться с их применением на мастер-классах.

Хорошая новость номер три: мы открыли видео всех докладов DevOpsConf 2019 и HighLoad++ 2019 — хотите больше хардкора, вам сюда.

Подобные полезности мы собираем в нашей рассылке — подпишитесь, пригодится.

Вобщем у меня такая беда :)
Лазил я себе в браузере..и решил закрыть его с трея (ну правой кнопкйо закрыть) так вот с тэого все началось)
Теперь у меня иконки индикатора клавы,сетки,и часов находятся рядом с кнопкой пуска + к этому не видно прог которые я свернул.. пытался поставить их обратно но незнаю как чесно говоря(
Извините за нубский вопрос. Жду ответа с нетерпением, а то глаза мозолит;)

"трей", "кнопка пуск". у тя точно линукс?))

Тебе нужно добавить на главную панель "Панель задач", тогда всё появится, но терминологию тебе придётся учить, слова "Кнопка пуск", "трей" и прочее - никуда не годится.

ну я не знаю как кнопка эта называется поэтому так назвал--главное чтобы вы поняли меня))
А можно весь процесс добавления панели задач поподробней - я в системе 1 день)

Вообще-то "Системный лоток" кде/гнома так же называется треем (system tray - системный лоток) И название это вовсе не из винды.

Это да! Но явно не "Пуск")))

если первый день, то

завершение сеанса - меню - консольный вход

и тама rm -rd /.kde

потом опять вход в иксы и будет вам счастие в виде дефолтных настроек

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

настройки firefox в папке

Та полоска внизу экрана называется "Панель КДЕ"
Это очень универсальная и гибконастраиваемая панель. Всё что на ней находится, называется "аплеты".
То, что виндузятники называют "кнопка пуск" называется "К-Меню" или "Меню КДЕ". системный лоток он и в африке системный лоток. по-английски - систем трэй, по-русски - системный лоток.
Все аплеты в KDE 3.5.9 можно добавлять на панель в любом порядке, перемещать их и настраивать некоторые их параметры.

Судя по описанию ситуации у тебя пропал аплет "Список окон". Попробуй добавить его опять. для этого кликни правой кнопкой мыши по панели и выбери пункт "Добавить аплет на панель"

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

По умолчанию панель расположена в нижней части экрана и разделяется на следующие части:

Мы все эти элементы управляющей панели воспринимаем как единое целое, хотя на самом деле это отдельные программы, которые мы можем добавлять или удалять. Такие программы не могут быть запущены самостоятельно в отдельном окне, а являются дополнениями к элементам интерфейса операционной систем.

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

Чтобы отключить или включить апплет, необходимо нажать на кнопку «Добавить на панель». Некоторые апплеты имеют настройки, при этом появляется кнопка «Настроить». Настройки у разных апплетов отличаются и порой весьма существенно, так как разные апплеты выполняют различные задачи.

Кроме установленных по умолчанию апплетов, можно посмотреть доступные апплеты на сайте в интернете и при желании их установить. Для этого нужно переключиться на соответствующую вкладку.

Единственное на что хочу обратить внимание, что не все дополнительные апплеты (представленные на соответствующей вкладке) могут работать корректно. Дело в том, что некоторые из них могут быть созданы для предыдущих версий Linux и не учитывать особенности новой операционной системы.

Продолжаем расширять возможности Линукс и сейчас обратимся к модулю «Дисклеты» раздела «Параметры».

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

Также есть еще одна вкладка в окне дисклетов, позволяющая настроить их оформление и размещение.

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

Насколько полезны дисклеты можете судить только вы сами. Я не пользовался гаджетами в Windows и не использую дисклеты, хотя некоторым пользователям данные виджеты нравятся.

В отличие от апплетов и дисклетов с Linux Mint Cinnamon не устанавливаются расширения и их нужно дополнительно скачивать с сайта. Схема работы и возможные проблемы тут такие же как при работе с дисклетами и апплетами.

Длинный ответ: официальное название штуковины снизу экрана — «панель задач» (taskbar). Она состоит из нескольких элементов — кнопка «Пуск», кнопки переключения между задачами, часы, и «область уведомлений» (taskbar notification area).

Распространённая ошибка — называть область уведомлений «треем» (или даже «системным лотком»). Она никогда так не называлась. Если вы встретите в документации упоминание «system tray», можете доложить, что обнаружили ошибку.

Откуда взялось это неверное название?

В ранних версиях Chicago — ещё до того, как проект получил название Windows 95 — панель задач была не панелью задач, а папкой, зафиксированной снизу экрана. Она была всегда на виду, и можно было «бросать» в неё документы и ярлыки для быстрого доступа — аналогично лотку для всякой всячины, который ставят в верхний ящик письменного стола.

Оттуда и взялось название «лоток (tray) рабочего стола». Немного сомнительное продолжение метафоры «рабочего стола на экране» — но всё ещё в пределах здравого смысла. (Вот если бы вместо обоев на стол клали скатерть. )

Значки свёрнутых приложений ложились прямо на рабочий стол — так же, как в классическом интерфейсе Windows 3.x

Лоток можно было зафиксировать у любого края экрана, а можно было «открепить» и перемещать по экрану, как обычную папку.

Потом мы отказались от этой идеи. На всегда видимую панель решили поместить кнопки переключения между задачами. (В одной из версий Chicago пользователь может выбирать, использовать панель как лоток или как панель задач; а иконки свёрнутых приложений попадают и на рабочий стол, и на панель задач.)

Не все программы были готовы к тому, чтобы верх экрана занимал ряд вкладок, и от идеи пришлось отказаться. С другой стороны, код переключения «вкладок задач» был к тому времени уже готов, и проще было перерисовать вкладки, чтоб они выглядели, как кнопки — чем переписывать весь код, используя настоящие кнопки. Так кнопки переключения задач и остались замаскированными вкладками (окно класса SysTabControl32 ).

Диахроническая справка: функциональность лотка осталась в системе. Пользователь мог подтащить любую папку к краю экрана, чтобы зафиксировать её как новую панель, или как элемент существующей панели. Одна такая панель, «быстрый запуск», добавленная с IE4, частично повторяла назначение исходного лотка — хранение часто нужных ярлыков. Парадоксально, но в Windows 7 видим возвращение панели задач к этой исходной концепции лотка для ярлыков.

Кнопки-вкладки превратились, как и положено ряду кнопок, в панель инструментов (окно класса ToolbarWindow32 ). Это произошло в Windows XP, когда панель задач впервые после Windows 95 обновили; а начиная с Windows 7, это окно нового уникального класса MSTaskListWClass .

Область уведомлений (ряд значков) была панелью инструментов ( ToolbarWindow32 ) с самого начала, и остаётся ей до сих пор.

Так вот, когда мы решили сделать вместо лотка панель переключения задач, мы прошерстили всю нашу документацию, и заменили упоминания слова «tray» на «taskbar». Нигде в документации Windows Shell слово «tray» больше не упоминается.

Примерно в это же время мы добавили на панель задач область уведомлений.

Наверное, её стали называть «system tray» из-за того, что в Windows 95 была программа systray.exe , отображавшая стандартные значки уведомлений: регулятор громкости, статус PCMCIA, индикатор зарядки батареи. Если завершить процесс systray.exe , значки уведомлений пропадают. Так что пользователи решили, «Ага, systray — это системный процесс, отвечающий за область уведомлений; наверняка она называется 'system tray'.» Заблуждение, которое из-за этого возникло, мы уже восемь лет пытаемся искоренить…

К сожалению, ради обратной совместимости пришлось оставить Tray в названиях оконных классов: Shell_TrayWnd у панели задач, TrayNotifyWnd у области уведомлений, и TrayClockWClass у часов. Но и во всех этих случаях «tray» относится к панели задач целиком — с тех времён, пока она была лотком.

Что хуже всего, разработчики других компонентов Windows и других продуктов Microsoft втянулись во всеобщее заблуждение, и теперь название «tray» встречается в их официальной документации и в примерах кода. Некоторые даже имеют наглость заявлять, что «system tray» — это официальное название области уведомлений.

Неправда. Область уведомлений никогда не была треем: она появилась, когда трей-лоток уже не существовал. Она всегда назвалась областью уведомлений, а значки в ней всегда назывались значками уведомлений (notification icons).

Ну и какое мне дело? Раз теперь все называют её треем, пора бы уже привыкнуть?
Нет. Вот вам бы понравилось, если бы все называли вас чужим именем?

Читайте также: