Double Commander — кроссплатформенный файловый менеджер с открытым исходным кодом и двумя панелями.
Запуск новая бета-версия Double Commander 1.1.2, лкоторый устраняет ошибки и проблемы, обнаруженные в бета-версии 1.1.1, выпущенной всего несколько недель назад.
Для тех, кто не знает о двухпанельном файловом менеджере: Двойной командир, который пытается воспроизвести функциональность Total Commander и обеспечить совместимость с его плагинами.
В современном мире, где информационные технологии становятся неотъемлемой частью бизнес-процессов, надежность и доступность сетевой инфраструктуры приобретают критическое значение. Именно здесь сервис Ping-Admin выходит на первый план, предоставляя широкий набор инструментов для мониторинга и управления сетевой инфраструктурой. Давайте рассмотрим подробнее, что делает Ping-Admin уникальным и какие преимущества он предоставляет.
Сервис Ping-Admin представляет собой неотъемлемый инструмент в современном мире IT-технологий. Его возможности по мониторингу, управлению и анализу сетевой инфраструктуры позволяют бизнесам и специалистам в области IT обеспечивать надежность и стабильность работы своих ресурсов. С Ping-Admin ваша инфраструктура под надежной охраной, готовой к вызовам современного бизнеса.
Современный бизнес сталкивается с необходимостью постоянного анализа и оптимизации своей деятельности для достижения успеха. В этом контексте, инструменты аналитики играют ключевую роль. Среди них особое место занимает сквозная аналитика, которая предоставляет комплексное представление о процессах внутри организации. https://daria-dein.ru/ — Построение сквозной аналитики. Разработка системы согласно задачам бизнеса В данной статье мы рассмотрим, где и как применяется сквозная аналитика, и какие выгоды она приносит бизнесу.
Одной из основных областей применения сквозной аналитики является маркетинг и реклама. С ее помощью можно отслеживать эффективность рекламных кампаний на всех этапах взаимодействия с клиентом — от первого контакта до совершения покупки. Системы сквозной аналитики позволяют анализировать маркетинговые каналы, определять наиболее эффективные и выделять удачные стратегии для привлечения аудитории.
Сквозная аналитика помогает повысить эффективность продаж, позволяя отслеживать каждый этап воронки продаж — от первого контакта клиента до завершения сделки. Анализируя данные о поведении покупателей, компании могут оптимизировать свои стратегии продаж, улучшая конверсию и увеличивая выручку.
Сквозная аналитика позволяет компаниям полноценно контролировать и улучшать клиентский опыт. С ее помощью можно анализировать взаимодействие с клиентами на всех этапах их пути, идентифицировать слабые места и предлагать улучшения. Это способствует удержанию клиентов и повышению их лояльности.
Сквозная аналитика не ограничивается только клиентской сферой. Ее применение также распространяется на управление производственными процессами. Путем анализа данных о производстве и логистике компании могут оптимизировать свои операции, сокращая издержки и повышая эффективность.
Эффективный анализ финансов — залог успешного бизнеса. Сквозная аналитика предоставляет комплексный инструментарий для мониторинга финансовых показателей. Она позволяет в реальном времени отслеживать бюджеты, анализировать затраты и доходы, прогнозировать финансовые показатели на будущее.
Сквозная аналитика представляет собой мощный инструмент, позволяющий компаниям анализировать свою деятельность в комплексе и принимать обоснованные решения. От маркетинга и продаж до управления клиентским опытом и финансовой деятельностью — ее применение неограничено. Компании, освоившие этот инструмент, имеют значительное преимущество перед конкурентами, что позволяет им быть более адаптивными и эффективными в современной бизнес-среде.
В быстро развивающемся ландшафте компьютерной архитектуры одна концепция стала движущей силой повышения производительности современных процессоров: параллелизм на уровне потоков (TLP). TLP относится к способности процессора выполнять несколько потоков одновременно, что позволяет более эффективно использовать доступные ресурсы и обеспечивает значительный прирост вычислительной производительности. В этой статье рассматриваются тонкости TLP, его значение, механизмы и роль в формировании будущего вычислительной техники.
Параллелизм на уровне потоков использует преимущества присущего программным программам параллелизма. Традиционно процессоры выполняли инструкции последовательно, ограничивая потенциал ускорения, особенно в приложениях с изначально распараллеливаемыми задачами. TLP вносит сдвиг в парадигму, позволяя процессору выполнять несколько потоков одновременно, эффективно разбивая сложные задачи на более мелкие, более управляемые фрагменты, которые могут обрабатываться одновременно.
Ниже приведены три типа параллелизма на уровне потоков:
Механизмы использования параллелизма на уровне потоков (TLP) приведены ниже:
Ниже приведены некоторые значения параллелизма на уровне потоков (TLP):
Закон Амдала: Несмотря на свои преимущества, TLP сталкивается с уменьшающейся отдачей по мере увеличения количества потоков из-за последовательных частей программы.
Накладные расходы на синхронизацию: Управление параллельными потоками требует тщательной синхронизации, чтобы избежать условий гонки и обеспечить согласованность данных.
Иерархия памяти: Конкуренция потоков за общие ресурсы, такие как кэш и пропускная способность памяти, может повлиять на производительность.
Заключение
Параллелизм на уровне потоков стал краеугольным камнем современной компьютерной архитектуры, позволяя процессорам использовать возможности нескольких потоков для достижения повышенной производительности. Поскольку программные приложения становятся все более сложными и требовательными, TLP продолжает играть ключевую роль в формировании эволюции процессоров, позволяя им удовлетворять постоянно растущие вычислительные потребности современного мира. От многоядерных процессоров до гиперпоточности, TLP является движущей силой неустанного стремления к более быстрым и эффективным вычислениям.
1. Чем TLP отличается от других форм параллелизма?
TLP фокусируется на одновременном выполнении нескольких независимых потоков, в отличие от других форм параллелизма, таких как параллелизм на уровне команд (ILP) и параллелизм на уровне данных (DLP), которые имеют дело с параллельным выполнением инструкций или обработкой данных в рамках одного потока.
2. Какова роль многоядерных процессоров в TLP?
Многоядерные процессоры воплощают TLP, имея несколько независимых вычислительных ядер на одном чипе. Эти ядра могут выполнять разные потоки одновременно, эффективно увеличивая доступную мощность параллельной обработки.
3. Что такое одновременная многопоточность (SMT)?
Одновременная многопоточность, часто известная как гиперпоточность, — это технология, которая позволяет одному физическому ядру выполнять несколько потоков одновременно. Это улучшает параллелизм на уровне потоков на уровне ядра и может повысить общую пропускную способность процессора.
4. Как TLP способствует повышению производительности?
TLP оптимизирует использование ресурсов, позволяя нескольким потокам выполняться одновременно, сокращая время простоя процессора. Это приводит к более быстрому завершению задачи и повышению общей производительности системы.
5. С какими проблемами сталкивается TLP?
Отдача от TLP уменьшается по мере увеличения количества потоков, поскольку определенные части программы могут оставаться изначально последовательными из-за зависимостей. Накладные расходы на синхронизацию и конкуренция за совместно используемые ресурсы, такие как кэш и память, также могут влиять на производительность.
Coreutils — это программный пакет, разработанный проектом GNU, который содержит несколько основных инструментов, таких как cat, ls и rm, необходимых для Unix-подобных операционных систем.
Новая версия GNU Coreutils 9.4 уже выпущена ипоставляется с различными улучшениями производительности, изменение поведения, исправления ошибок и многое другое. В этом выпуске освещаются изменения, внесенные в cp -v и mv -v, а также тот факт, что время безотказной работы теперь поддерживает Android и многое другое.
Те, кто не знает о пакете Coreutils, должны знать, что это Это комбинация трех предыдущих пакетов.: файловые утилиты (fileutils), утилиты интерпретатора команд (shellutils) и утилиты обработки текста (textutils).
В работе любой программист или системный администратор встречается со страшной проблемой — тормозит база. Сервер работает медленно, происходит нечто непонятное, пользователи жалуются, клиент ругается. Я не зря написал, что проблема является страшной, в первую очередь потому, что решение здесь будет неочевидное и лежит оно не на поверхности. На производительность базы может влиять множество параметров.
В этой статье я постарался рассмотреть большинство из них, а также перечислю те команды, которые помогают мне понять причины медленной работы сервера или базы данных.
Ниже перечислю этапы, по которым вам следует пройтись, чтобы понять причины проблемы.
1. Смотрим, что было сделано раньше.
Для этого у вашего приложения должен быть Git. Заходим в него и смотрим, что было сделано ранее. Какие вы делали миграции, какие настройки меняли.
И желательно, чтобы основной файл конфигурации БД postgresql.conf также был в гите. Тогда вы сможете в том числе контролировать и изменение настроек базы.
Конечно, вы должны взять за правило — не делать никаких изменений в базе напрямую, а всё проводить через гит и миграции.
Особенно если речь идёт об изменениях структуры базы данных, добавлении обработчиков, пользовательских функций, процедур. Эти работы должны делать скрипты, которые, в свою очередь, должны версионироваться.
2. Смотрим, что происходит в операционной системе.
Если изменений в гите не было, а проблема возникла неожиданно, то следующее, на что стоит обратить внимание — что происходило в операционной системе.
Надеюсь, база данных у вас установлена на Linux-машине. Если нет, то советую подумать о переезде на Linux.
Вспомните, какие антивирусы или сетевые экраны вы устанавливали. Посмотрите, какие приложения или сервисы подняты на сервере, кроме базы данных. Оптимальный подход — держать на сервере только базу данных и ничего лишнего. Благо, текущие технологии по виртуализации позволяют это сделать очень быстро и просто.
3. Проверяем оборудование.
Опять же, если в операционной системе вы ничего не меняли, у вас уже стоит Linux, стоит обратить внимание на оборудование. Сегодня некоторые производители железа грешат качеством и нельзя надеяться на то, что память или жёсткий диск не выйдут из строя в самый неподходящий момент. Поэтому, первое на что советую обратить внимание:
htop
Если вы видите, что процессор загружен на 70% и более и при этом загружены все ядра, то подумайте об увеличении мощности. Процессоры сейчас дешёвые, а если вы используете виртуализацию, то добавьте вашей базе дополнительное количество ядер. Скорее всего, вашей базе перестало хватать мощностей из-за возросшей нагрузки и стоит подумать о модернизации сервера.
iostat –dx
Обратите внимание на последнюю колонку. Она вам даст представление о загрузке дисковой подсистемы. Если показатель приближается к 100%, то нужно подумать об увеличении памяти. Скорее всего, у вас очень большой размер базы данных, а оперативки на сервере для обработки данных слишком мало.
Помните, что расходы по оптимизации запросов или кода приложения не окупятся, если у вас присутствуют проблемы с оборудованием.
4. Установите систему мониторинга.
Попробуйте установить систему мониторинга Percona https://www.percona.com/software/database-tools/percona-monitoring-and-management. Её интерфейс показан на картинке выше. Она бесплатная и позволит вам быстро оценить динамику нагрузки на сервер и покажет все главные показатели работы сервера.
5. Проанализируйте файловое хранилище.
Запустите команду:
iostat –x
Посмотрите на колонки с постфиксов _await. Они говорят вам о показателе f/s latency. Если показатель больше 50 мс без нагрузки, то стоит задуматься. Если более 100 — то стоить предпринимать срочные меры.
Причиной высоких цифр может быть неверная настройка гипервизора или работа базы через NAS. Последнего подхода в проектировании нужно избегать.
6. Анализируем pg_stat_activity.
Итак, мы проверили сервера, оборудование, ничего необычного не нашли. Переходим непосредственно к тюнингу базы.
Первое, что приходит на ум — представление pg_stat_activity.
Сначала проверьте в настройках базы параметр track_activity_query_size, по умолчанию он выставлен на 1024. Увеличьте его как минимум в 2-3 раза, в большинстве случаев его не хватает.
Теперь ищем, какая активность у нас происходит в базе. Может всё гораздо проще и кто-то запустил сложный запрос и вам стоит остановить этот скрипт. Смотрим активные запросы длительностью более 5 секунд:
SELECT now() - query_start as "runtime", usename, datname, wait_event, state, query FROM pg_stat_activity WHERE now() - query_start > '5 seconds'::interval and state='active' ORDER BY runtime DESC;
Также могут вызвать подозрения запросы с состоянием «idle». А ещё хуже с состоянием «idle in transaction».
Такие запросы можно остановить следующими командами:
SELECT pg_cancel_backend(procpid);
SELECT pg_terminate_backend(procpid);
Первый остановит активные запросы, второй с типом idle.
Теперь стоит посмотреть, есть ли у вас зависшие трансакции. Выполняем запрос:
SELECT pid, xact_start, now() - xact_start AS duration FROM pg_stat_activity WHERE state LIKE '%transaction%' ORDER BY 3 DESC;
Помните, трансакции должны выполняться моментально. Из ответа смотрите на duration. Если трансакция висит несколько минут, а тем более часов, значит, приложение повело себя некорректно, оставив трансакцию незавершённой. А это влияет на репликацию, на работу VACUUM, WAL.
7. Анализируем pg_stat_statements.
Если раньше мы проверяли активные запросы, то теперь самое время проанализировать то, что было раньше. В этом нам поможет представление pg_stat_statements. Но обычно по умолчанию оно отключено, нам следует его активировать. Для этого в конфиге базы вставляем следующую строчку:
shared_preload_libraries = 'pg_stat_statements'
Затем в текущем сеансе работы с базой, запускаем команду:
create extension pg_stat_statements;
Если вы планируете заниматься производительностью базы, то оно вам нужно обязательно. Без него вы не сможете сделать многих вещей. Оно, конечно, займёт немного места на диске, но по сравнению с преимуществами это будет не страшно.
С помощью него вы можете получить статистику по уже выполненным запросам.
Например, мы можем получить запросы с максимальной загрузкой процессора такой командой:
SELECT substring(query, 1, 50) AS short_query, round(total_time::numeric, 2) AS total_time, calls, rows, round(total_time::numeric / calls, 2) AS avg_time, round((100 * total_time / sum(total_time::numeric) OVER ())::numeric, 2) AS percentage_cpu FROM pg_stat_statements ORDER BY total_time DESC LIMIT 20;
А максимально долгие запросы — вот такой:
SELECT substring(query, 1, 100) AS short_query, round(total_time::numeric, 2) AS total_time, calls, rows, round(total_time::numeric / calls, 2) AS avg_time, round((100 * total_time / sum(total_time::numeric) OVER ())::numeric, 2) AS percentage_cpu FROM pg_stat_statements ORDER BY avg_time DESC LIMIT 20;
Таким образом, мы можем понять, какие запросы сильно влияют на нагрузку нашей базы данных и оптимизировать их при необходимости.
8. Работаем с представлением pg_stat_user_tables
Таблица pg_stat_user_tables — ключевое конкурентное преимущество по сравнению с другими БД. С помощью неё мы, например, получить информацию о последовательном чтении с диска:
SELECT schemaname, relname, seq_scan, seq_tup_read, seq_tup_read / seq_scan AS avg, idx_scan FROM pg_stat_user_tables WHERE seq_scan > 0 ORDER BY seq_tup_read DESC LIMIT 25;
В верхней части таблиц будут как раз те самые операции, которые читали данные с диска. Если у таблицы больше 2000 записей, то такие операции должны производиться по индексу, а не с диска. Т.е. вы получите в первую очередь те запросы, которые вам потребуется оптимизировать.
Также вам следует посмотреть кеширование этих таблиц по представлению pg_statio_user_tables.
В этом вам помогут колонки heap_blks… и idx_blks…
9. Настраиваем память для PostgreSQL.
В зависимости от настроек сервера, настройки у вас будут примерно следующими:
effective_cache_size - 2/3 RAM
shared_buffers = RAM/4
temp_buffers = 256MB
work_mem = RAM/32
maintenance_work_mem = RAM/16
Но я рекомендую пользоваться специальными конфигураторами:
http://pgconfigurator.cybertec.at/ — продвинутый конфигуратор от Cybertec.
https://pgtune.leopard.in.ua/ — онлайн версия классического конфигуратора pgtune.
Эти инструменты помогут вам поставить нужные настройки за вас.
10. Настраиваем дисковую подсистему.
Если вам ничего больше ничего не помогло, то в крайнем случае вы можете выставить следующие настройки:
fsync=off
full_page_writes=off
synchronous_commit=off
Но в этом случае вы потеряете в надёжности хранения данных. Но если у вас PostgreSQL не является единственной системой по обработке данных и база асинхронно копируется в аналитические системы, то с такими настройками можно жить. Так как они снижают нагрузку на диск. Немного поясню по данным параметрам:
fsync – данные журнала принудительно сбрасываются на диск с кеша ОС.
full_page_write – 4КБ ОС и 8КБ Postgres.
synchronous_commit – транзакция завершается только когда данные фактически сброшены на диск.
checkpoint_completion_target – чем ближе к единице тем менее резкими будут скачки I/O при операциях checkpoint.
Ещё есть effective_io_concurrency – по количеству дисков и random_page_cost – отношение рандомного чтения к последовательному.
Впрямую на производительность не влияют, но могут существенно влиять на работу оптимизатора.
11. Настраиваем оптимизатор.
join_collapse_limit – сколько перестановок имеет смысл делать для поиска оптимального плана запроса. Интересный параметр. По умолчанию установлено 10, может имеет смысл повысить его в 10-20 раз.
default_statistics_target — число записей просматриваемых при сборе статистики по таблицам. Чем больше, тем тяжелее собрать статистику. Статистика нужна, к примеру для определения «плотности» данных.
online_analyze - включает немедленное обновление статистики
online_analyze.enable = on
online_analyze.table_type = "all"
geqo – включает генетическую оптимизацию запросов
enable_bitmapscan = on
enable_hashagg = on
enable_hashjoin = on
enable_indexscan = on
enable_indexonlyscan = on
enable_material = on
enable_mergejoin = on
enable_nestloop = on
enable_seqscan = on
enable_sort = on
enable_tidscan = on
12. Оптимизируем запросы.
Итак, вы нашли тяжёлые запросы, делаем по ним explain или analyze и первое на что вам следует обратить внимание — на следующие фразы:
— Seq Scan — значит, что запрос делается через последовательный перебор строк таблицы.
— Nested Loops — соединение с вложенными циклами.
Например, вас может насторожить следующий ответ базы:
Seq Scan ON test (cost=0.00..40.00 ROWS=20)
В ответе мы также видим, сколько строк будет обработано, а также стоимость первой строки..всех строк. Он считается достаточно оригинально, здесь стоит смотреть в относительном сравнении.
Также если Seq Scan по таблице, где rows более нескольких тысяч и при этом есть FILTER – в этом случае явно нужно посмотреть на поля в FILTER и найти подходящий индекс. Если не нашли – бинго, то одну из проблем вы решили.
Подробно описывать оптимизацию запросов я описывать не буду, это тема отдельной статьи.
Логика чтения плана запроса проста:
1) Смотрим на самый большой cost оператора
2) Это Seq Scan или nested loops?
3) Смотрим следующий по стоимости оператор
Оптимизация чаще всего заканчивается либо добавлением индекса, либо упрощением запроса (разбиением на части, использованием вложенных таблиц и т.п.), либо обновлением статистики, как это ни странно.
Для чтения планов рекомендую использовать следующий сервис:
Что если проблема воспроизводится на проде?
В этом случае, вам надо воспользоваться параметром auto_explain. Он позволяет складировать ответ оптимизатора в одной папке. Включается следующим параметром:
session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '3s‘
auto_explain.log_analyze = true
Теперь нам понадобится файлы вывести в красивом виде. В этом нам поможет pgBadger. Генерирует красивый html, но в настройках «можно утонуть».
Вот так выглядит самая простая настройка:
pgbadger -j 4 -p '%t [%p]:[%l-1]' /var/log/postgresql/postgresql-9.6-main.log -o bad.html
На Prod auto_explain лучше не включать, или включать в крайнем случае и на короткое время. В случаях, если у вас нет просадки по ресурсам.
Стоит выделить наиболее часто встречающиеся ошибки:
shared_preload_libraries = ‘pgmemcache’
CREATE EXTENSION pgmemcache;
memcache_server_add('hostname:port'::TEXT)
Использование:
memcache_add(key::TEXT, value::TEXT)
newval = memcache_decr(key::TEXT)
memcache_delete(key::TEXT)
Если нужно кэширование внутри СУБД или временную таблицу в памяти. Но часто удобно использовать одну ORM или фреймворк имеет ограничения, или просто нужно оперативно заменить таблицу на inmemory KV хранилище.
— PostgreSQL используется в качестве OLAP. Самый простой вариант — быстро перенести данные в columnstore. https://github.com/citusdata/cstore_fdw
В данной статье я перечислил основные проблемы, с которыми сталкиваются разработчики при работе с базами данных. Если у вас есть интересный кейс или опыт, буду рад, если вы его пришлёте мне по электронной почте.
Источник: https://sergeyem.ru/blog/68