статус idle что это

[инглиш]Как перевести слово Idle

Re: [инглиш]Как перевести слово Idle

Re: [инглиш]Как перевести слово Idle

«простой» (в смысле, ничего не происходит, простаивает). с учетом специфики ЛОРа можно переводить как «уныние».

Re: [инглиш]Как перевести слово Idle

Re: [инглиш]Как перевести слово Idle

Напиши в контексте

Re: [инглиш]Как перевести слово Idle

Re: [инглиш]Как перевести слово Idle

О этот прожорливый System Idle!

Re: [инглиш]Как перевести слово Idle

это не контекст, а перевод 😉

Re: [инглиш]Как перевести слово Idle

Спасибо, простой вроде подходит 🙂

Re: [инглиш]Как перевести слово Idle

Тогда ещё вопрос. Если в аське контакт обозначен как Idle, то что это значит? У меня в копыте пишется, мол контакт Idle столько то часов, столько то минут.

Re: [инглиш]Как перевести слово Idle

Re: [инглиш]Как перевести слово Idle

Пыджын пишет это idle и ставит статус «Отошел» )

Re: [инглиш]Как перевести слово Idle

Ну а что это значит? Контакт в офлайне, но со статус у него Idle. Это значит, что он выходил в онлайн или нет?

Re: [инглиш]Как перевести слово Idle

> Все словари переводят как «праздный».

Ого, так у меня праздная фриибсд.

Re: [инглиш]Как перевести слово Idle

idle
adjective, verb
adjective
1 (of people) lazy; not working hard:
an idle student
2 (of machines, factories, etc.) not in use:
to lie / stand / remain idle
3 (of people) without work; unemployed:
Over ten per cent of the workforce is now idle.
4 [usually before noun] with no particular purpose or effect; useless:

idle
adjective
1 : lacking worth or basis : VAIN
2 : not occupied or employed: as a : having no employment : INACTIVE b : not turned to normal or appropriate use c : not scheduled to compete 3 a : SHIFTLESS, LAZY b : having no evident lawful means of support

verb
intransitive senses
1 a : to spend time in idleness b : to move idly
2 : to run at low power and often disconnected usually so that power is not used for useful work transitive senses
1 : to pass in idleness
2 : to make idle
3 : to cause to idle

Re: [инглиш]Как перевести слово Idle

> Тогда ещё вопрос. Если в аське контакт обозначен как Idle, то что это значит? У меня в копыте пишется, мол контакт Idle столько то часов, столько то минут.

Значит, «бездействующий». Применительно к аське это значит, что контакт залогинился, но затем в течение какого-то времени не совершал никаких действий на компьютере.

Источник

BGP: Установление сессии между пирами

Перед тем как перейти к более практическому материалу, а именно настройке протокола BGP, нужно понимать, в каких состояних может находиться BGP роутер, и собственно как устанавливается сессия.

Idle — первое состояние, через которое проходит роутер, при активации BGP роутер переходит в него и сразу же пытается установить с пирами соединение, тоесть переходит в следующее состояние

Connect — BGP ожидает TCP соединение

Active — Инициация TCP соединения. Если соединение не установлено, то роутер переходит в режим Connect, после нескольких попыток переходит в Idle.

OpenSent — BGP ожидает OPEN сообщения (помните была заметка о сообщениях которые посылает BGP? ), после получения такого сообщения, проверяются все обязательные атрибуты, если что-то не так, то посылается NOTIFICATION сообщение с указанием ошибки.

Если все ок, BGP начинает посылать KEEPALIVE сообщение, сбрасывает таймеры. Если таймеры keepalive установлены у пиров разные, устанавливается минимальное значение. Если на этой стадии обнаружен разрыв TCP сессии, роутер переходит в Active State.

OpenConfirm — после согласования KEEPALIVE на данной стадии дожидаемся прихода этого сообщения, если оно пришло, все ок, мы переходим к следующей стадии.

Established — на этой стадии осуществляется обмен маршрутами.

Уточню еще один момент, есть возможности роутера BGP, которые должны быть согласованы с пиром, такие возможности (capability) согласовываются в Open сообщении (Optional Parameter помним, вот как раз в нем).

С помощью этой капабилити описываются согласовываются такие вещи как: ORF и Route Refrash (эти технологии мы обязательно рассмотрим в последующих заметках).

После того, как мы с Вами выяснили какие состоянии есть у BGP роутера, можем переходить к настройке BGP, и разбор всех технологий которые там есть.

Источник

Нюансы работы с PostgreSQL в 3 кейсах от DBA

Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.

Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.

Кейс первый

Ситуация с idle in transaction – приложение открыло транзакцию, отправило изменения в базу данных, а закрыть транзакцию забыло, транзакция висит.

Как решать инженеру такие ситуации? В Интернете можно найти много статей на тему: что такое idle in transaction, с чем оно связано и даже на практике посмотреть примеры реализации этой ситуации, но не получите самую главную информацию – как решать такие проблемы?

У нас была ситуация, когда появились idle in transaction, и приложение начало тормозить – пул подключений в базе данных был забит. Они блокировали ресурсы, и нам нужно было срочно принимать какое-то решение, мы пошли самым простым путём, который напрашивается и предлагается вашему вниманию.

Первый вариант, который может быть – это выполнение команд:

select pg_cancel_backend(pid) from pg_stat_activity where state = ‘idle in transactions’ and datname = ‘название_БД’; или

select pg_terminate_backend(pid) from pg_stat_activity where state = ‘idle in transactions’ and datname = ‘название_БД’;

А может ли упасть PostgreSQL?

Точечно отстреливать запросы, можно вызвать групповую команду по маске – очевидные плюсы. Но эти команды на самом деле не решают проблему с idle in transaction. Когда ситуация возникает на стороне бэкенда и мы выполнили команду, которая группой срубила запросы, то через некоторое время ситуация может повториться и тут же появятся от бэкенда запросы в статусе idle in transaction.

Другой вариант – перезагрузка сервера PostgreSQL

Какие в этом решении могут быть минусы? Конечно же, остановка сервера. К тому же часто бывает, что на одном кластере находится не одна база, а несколько или даже с десяток разных баз.

При остановке сервера PostgreSQL мы убиваем подключения к другим базам или подключения других сервисов. Все это усугубляется ситуацией, когда приложение автоматически не может переподключится к базе. Да бывает и такое! Что может привести к каскадному эффекту в перезагрузке сервисов.

Не знаю, если ли тут плюсы?

Ещё вариант – перезагрузка бэкендов

Через pg_stat_activity определяем IP проблемного сервиса, с которого произошло подключение. Начинаем их перезагружать. В мире IT микроархитектуры этот процесс не будет являться существенной проблемой.

В нашей ситуации получилось таким образом: увидели idle in transaction – начали пачками отключать запросы. Но количество соединений с базой данных не изменялось. Тут же появлялись новые в этом же статусе. Потом мы подумали: нужно перезагружать PostgreSQL.

От этой идеи быстро отказались, потому что у нас были другие сервисы и была вероятность, того, что после перезагрузки PostgreSQL они не поднимут заново соединение с базой. Поэтому мы через pg_stat_activity нашли бэкенды, которые забивают весь пул подключений, и их перезагрузили.

Еще есть другой вариант, не рассмотренный нами выше. Если вы используете инструмент управления пулом соединений, например pgbouncer, то ситуация решилась бы довольно просто:

– установка pgbouncer на паузу – команда pause;

– перезагрузка сервера PostgreSQL;

– снятие pgbouncer с паузы – команда resume.

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

В августе 2021 провели митап с Иваном по нюансам работы с PostgreSQL.

Кейс второй

СУБД PostgreSQL работает с диском, оперативной памятью, процессором. Если выходит аппаратная часть оборудования, то идём и чиним. Но иногда бывают и скрытые проблемы, например сбой в дисковом массиве, который мы можем заметить не сразу, можем вообще не знать об этом.

Давайте воспроизведем проблему сбоя дисковой подсистемы, затем покажем её решение. У нас есть PostgreSQL – тринадцатая версия. Создадим базу и инициализируем pgbench. Она существует, чтобы нагружать сервер, снимать метрики производительности. Но нам она нужна для других целей.

Рассмотрим таблицу pgbench_branches, в ней есть три поля и одна запись.

Найдем, где находится физически эта таблица на диске:

Остановим кластер PostgreSQL. Откроем файл base/16839/16853 и допишем любой текст в середине файла. Сохраним его.

Запустим PostgreSQL. Попробуем прочитать данные из таблицы.

В таблице также одна запись, но теперь в ней просто пустые строки.

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

Как проблему можно решить? Если мы посмотрим: включена ли у нас контрольная сумма страниц данных в кластере, то мы увидим, что off. Когда PostgreSQL обращается к данным, он рассчитывает контрольную сумму данных страницы, сравнивая её с сохраненной в заголовке страницы, и если она не соответствует, то он выдаёт ошибку.

Насколько это просаживает перформанс? Есть статистика, что – от одного до трёх процентов, но при этом вы точно знаете, что данные у вас повреждены или не повреждены. Это стоит того, чтобы включать контрольную сумму данных у себя. В девелоперской базе неважно. В препроде на ваше усмотрение. А в продовской обязательно должно быть включено.

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

Проделаем ту же процедуру с повреждением данных, что и ранее.

И теперь если прочитаем данные из таблицы pgbench_branches увидим, что у нас появилась ошибка о несовпадении контрольных сумм.

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

Часто приложения используют только оперативные данные. PostgreSQL не обращается к старым страницам данных. И если в них есть повреждения, то мы можем узнать об этом слишком поздно, когда в резервных копиях тоже будут содержаться они.

Для проверки каталога данных можно воспользоваться командой checkdb в утилите pg_probackup. Хотя данная утилита создана для создания/восстановления резервных копий, в ней есть дополнительный инструмент проверки рабочего каталога базы данных и целостности индексов.

Пример из жизни. Запросы шли в базу и некоторые их них повисали. На сутки, двое, трое. Потом пул запросов стало большим и они начал забирать всю оперативную память. Приходил omm killer и убивал PostgreSQL.

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

Предполагали три варианта:

что-то с картой видимостью,

что-то с индексами на этой таблице,

что-то с данными в самой таблице.

Решили удалить индексы и посмотреть, что будет – как только мы это сделали у нас приложение перестало работать. Это был фейл – приложение не работало три часа. Но нам стало сразу ясно, где проблема. Индексы ссылали на данные, которых нет в БД (страница данных нулевого размера).

Как вышли из ситуации? Создали новую пустую таблицу и по блокам перетаскивали данные со старой таблицы в новую. Потом били блоки на меньшего размера и так до тех пор пока не выявили семнадцать битых строк, для которых были ссылки в других таблицах, но в целевой отсутствовали.

ЕЩЁ. Под спойлером о курсе по PostgreSQL от Ивана.

23–25 сентября 2021 года Иван проводит второй поток обучения продвинутого курса по PostgreSQL.

Кейс третий

Кейс разбит на три ситуации и они о предотвращении проблем, а не исправлении.

Ситуация номер один

У нас есть три таблички: заказы, продукты и таблица, которая связывает многие ко многим. В какой-то момент времени бизнес решил, что нужно сравнивать значения в одно регистре, обратите внимание на тип у колонки id в таблице orders. Можно со стороны приложения переводить все данные к нижнему или верхнему регистру и делать сравнение в запросе. Но можно воспользоваться встроенным типом данных citext. Рассмотрим, как разработчики решили переходить на новый тип данных.

Первая команда у нас создаст эксклюзивную блокировку, которая дропнет constraint. Достаточно быстрая операция. Вторая – по изменению типа, он относится к одному виду типов, поэтому быстрее заменится, проблем с этим не будет. Далее меняем тип на связные таблицах и пытаемся создать constraint.

Что у нас получается – эксклюзивная блокировка на две таблицы product orders и orders, чтобы данные не изменялись. И это будет выполняться в одном потоке. Когда у нас 100-200 записей, то проблем нет – это доли секунды. Если записей стало больше, миллионы, тогда эти внешний ключ будет накатываться очень долго.

Разработчики выкатывают релиз, и у нас останавливается сервис. Моя была ошибка, что пропустил этот pull request. Разобрались, срубили запрос. Ночью мы остановили сервис бэкенда, накатили sql-скрипты.

Ситуация номер два, из жизни

Представим, что есть таблички folders и folder_files. Мы хотим пробежаться по всем подпапкам и вытаскивать файлы, которые там есть. Когда у нас десятки-сотни тысяч записей, то проблем нет. Но когда появляются десятки миллионов записей, то тут нужно искать другие способы раскрутки дерева.

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

Было выбрано решение – разделить запрос на два:

отдельно рекурсивное cte, ограничив его по уровню вложенности;

отдельно маппинг результата cte с данными.

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

Ситуация три – немного о другом

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

Загрузка CPU доходит до полтинника. Проблемы наблюдаются достаточно давно. Нагрузка 50% – это не критично. Нагрузка по диску каких-то 400 ops.

Пик в районе трёх часов не относится к данной ситуации

Смотрим логи, а там постоянно такие записи.

Вставка 62 секунды. Копаем дальше, смотрим различные метрики. И видим, что в таблице items отсутствуют первичный ключ. При вставке данных в таблицу history из-за внешнего ключа проверялось наличие записи в таблице items. Починили.

Проблему не решило. Копаем дальше, смотрим представление pg_statio_all_tables и раскрываем всю суть.

Запрос select * from pg_statio_all_tables показывает кто генерит большую нагрузку на диск. Первая строчка history_text_default. В дефолтовую секцию ничего не должно писаться, но именно она создает нагрузку на диск. А количество чтений с диска на три порядка больше, чем в позиции на втором месте. Дефолтовая секция, большое количество чтений с диска – и мы понимаем, что перестало работать секционирование таблицы history_text.

Как только мы устранили проблему, деградация системы прекратилась и приложение заработало.

Надеемся, что кейсы были полезны. Под спойлером о курсе по PostgreSQL от Ивана.

А вот, что ждёт инженеров, которые пройдут продвинутый курс Ивана по PostgreSQL:

— Научитесь оценивать состояние кластера в критический момент, принимать быстрые и эффективные решения по обеспечению работоспособности кластера.

— Узнаете, как внедрить новое оптимальное архитектурное решение в своей команде, а также сможете лидировать этот процесс.— сэкономите компании время и деньги путем оптимизации процессов администрирования.

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

Источник

Режим IDLE (свободное состояние)

Когда MS находится в свободном состоянии она постоянно осуществляет измерения BCCH несущих обслуживающей соты и близлежащих сот. Посредством этих измерений она решает, какую соту захватить.

Существует несколько причин захвата соты MS:

1. Захват соты даёт возможность MS получить системную информацию о сети.

2. MS устанавливает соединение посредством доступа в систему на канале RACH в соте, в которой она располагается после ее захвата.

3. Сеть должна знать, в какой LA находится MS (быстрый пейджинг MS)

В свободном режиме (режим IDLE) MS может выполнять 4 основных процесса:

· Выбор сети PLMN (PLMN selection)

· Выбор соты (Cell Selection)

· Перевыбор соты (Cell Reselection)

· Обновление местоположения (Location updating).

Рис. 7.3 Процессы в режиме IDLE

Как только MS включается или входит в зону обслуживания PLMN она выбирает сеть PLMN. Сначала MS пытается найти старую сеть. Если MS находит эту сеть, она регистрируется в этой сети и на дисплее трубки высвечивается наименование зарегистрированной PLMN (“registered PLMN”). После регистрации MS может устанавливать соединения и принимать вызовы. В случае, если MS не может найти старую PLMN или зарегистрироваться в ней, она пытается выбрать другую сеть. Это осуществляется либо в автоматическом режиме, либо вручную.

В автоматическом режиме используется список существующих сетей PLMN, записанных в SIM-карте трубки, в то время как ручной режим предполагает использовать сеть по выбору и показывает сети доступные в данный момент. Обычно MS работает с собственной PLMN. Другая сеть PLMN может быть выбрана в том случае, если MS находит подходящую для себя сеть. Например, собственная сеть не обнаружена, а есть какие-либо другие разрешенные PLMN. После выбора подходящей сети происходит обновление местоположения (location updating). Регистрация MS произойдёт только в том случае, если MS будет способна осуществить доступ в систему. С другой стороны, для MS нет необходимости осуществлять обновление местоположения, если MS располагается в той же самой LA, принадлежащей той же PLMN, в какой она находилась до неактивного состояния.

Автоматический режим

Если MS в автоматическом режиме не видит ранее использовавшуюся PLMN (сеть не доступна), и если существует другая доступная PLMN, то MS выбирает новую PLMN. PLMN доступна в следующих случаях:

1. PLMN – собственная сеть;

2. доступна какая-либо PLMN, информация о которой хранится в SIM-карте в приоритетном списке;

4. существуют другие PLMN в порядке уменьшения уровня сигнала.

Ручной режим

В случае, если последней зарегистрированной PLMN не существует, MS будет пытаться выбрать зарегистрированную или собственную PLMN. Если регистрация не выполняется или если абонент инициировал процедуру перевыбора PLMN, то MS отобразит на дисплее наименования всех доступных PLMN. После чего абонент может выбрать предпочтительную PLMN и зарегистрироваться в ней. В случае, если выбранная PLMN не доступна, абоненту будет предложена другая сеть из списка определенных PLMN. Таким образом, абонент может выбирать сети PLMN из того списка, в котором они были определены в MS.

Выбор соты (Cell Selection)

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

На данной стадии при выборе сот существует две различных стратеги:

· Stored list selection. Список, в котором указываются номера каналов BCCH – список BA (BCCH Allocation list). Данный список используется для ускорения процесса выбора сот.

· Normal cell selection. Обычная процедура выбора сот. Данная процедура выполняется в случае, если список BA недоступен.

Алгоритм

Выбор сот. (Normal cell selection)

При реализации стратегии normal cell selection MS пытается выбрать наиболее подходящую соту.

Сота считается подходящей если:

· Сота принадлежит выбранной PLMN.

· Сота не запрещена. (Когда сота запрещена, MS не может расположиться на ней находясь в режиме IDLE, но если MS находится в активном режиме (в разговорном состоянии), на эту соту может быть осуществлён хендовер);

· Выполняется критерий выбора сот.

· Сота не принадлежит LA, которая находится в списке «запрещённые зоны местоположения для национального роуминга»

Критерий выбора сот

Данный критерий основывается на оценке потерь на трассе.

Пока MS находится в состоянии IDLE она постоянно вычисляет параметр С1. Критерий выбора соты основывается на соотношении: С1>0.

Данный параметр определяется как:

Таблица 7.1 – Описание параметров для критерия выбора сот

Все выше приведённые параметры выражаются в dBm.

Перевыбор сот (Cell Reselection)

Алгоритм

Измерения при перевыборе сот (Cell reselection measurements)

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

MS постоянно контролирует все несущие BCCH близлежащих сот, которые показаны в списке BA, и несущую BCCH обслуживающей соты, чтобы определить другую более подходящую соту. Требуется по крайней мере 5 попыток измерения принятого сигнала для каждой определённой близлежащей соты. Усреднение принятого уровня сигнала выполняется для каждой несущей для списка BA.

Чтобы контролировать изменения в параметрах соты сообщения системной информации, переданные на несущей BCCH, читаются один раз за 30 секунд. Кроме этого, MS пытается засинхронизироваться с системой, чтобы каждые 5 минут читать всю информацию, передаваемую по каналу BCCH. Эта информация содержит параметры, воздействующие на процесс перевыбора. Чтение информации осуществляется по каналам BCCH шести соседних сот, от которых прием идет с наиболее высоким уровнем сигнала. Список частот, а следовательно, и сот, на которых проводятся измерения, берется из списка BA.

MS пытается декодировать параметр BSIC для шести близлежащих сот, имеющих наиболее высокий уровень несущих (по крайней мере каждые 30 сек) чтобы подтвердить, что она ещё контролирует те же самые соты. Параметр BSIC состоит из двух частей:

Если обнаруживается другой BSIC, то MS обрабатывает его как новую несущую, и данные BCCH будут определены для этой несущей. Если мобильная станция обнаруживает цветовой код PLMN, который является недоступным, то данная несущая игнорируется.

Критерий перевыбора сот (Cell reselection criteria)

Чтобы контролировать распределение нагрузки между сотами оператор может отдавать предпочтение определённым сотам по его усмотрению. Основанием этого может служить процедура Locating и иерархическая структура сот. В некоторых ситуациях это может быть необходимо, но только в тех случаях, когда MS находится в состоянии IDLE. Кроме того, в микросотовой структуре это необходимо для того, чтобы контролировать скорость процесса перебора сот, в частности, для быстродвижущихся объектов. Для этих целей используются параметры CRO, TO, и PT, которые передаются на канале BCCH в каждой соте. До того, как MS получает возможность сменить соту для захвата другой соты, она должна прочитать параметр offset, который должен быть применён в алгоритме перевыбора сот. Информация о значении данного параметра получается по каналу BCCH обслуживающей соты.

В процессе перевыбора сот оценивается величина С2. Выбор соты производится по максимальному значению С2.

Параметр С2 подсчитывается следующим образом

, .

Параметры CRO, TO и PT определяются командой RLSBC (BSC)

CRO – Cell Reselection Offset – смещение уровня для перевыбора сот, [dB];

TO – Temporary Offset. Временное смещение, [dB];

PT – Penalty Time. «Штрафное время».

T – таймер;

Параметр С2 используется в том случае, если мобильная станция соответствует GSM фазы2. Конфигурация такой системы позволяет использовать данный параметр С2.

MS постоянно подсчитывает значения C1, C2 для обслуживающей соты и близлежащих сот. Если любой из ниже перечисленных критериев выполняется, то MS принимает решение перейти на другую соту.

Причины, по которым MS осуществляет перевыбор соты:

· Обслуживающая сота становиться запрещённой.

· MS обнаруживает, что сигнал в направлении downlink неудовлетворительный.

· Параметр С1 для обслуживающей соты меньше нуля (С1

Источник