TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #198 · 6 јан.

Первая директория в sys.path 🔸 Когда вы запускаете Python-интерпретатор в интерактивном режиме, в системные пути (sys.path) в самое начало добавляется текущая рабочая директория >>> for path in sys.path: ... print(f'"{path}"') "" "/usr/lib/python37.zip" "/usr/lib/python3.7" ... Первая строка пустая, что и означает текущую рабочую директорию. 🔸 Если вы запускаете интерпретатор передавая скрипт как аргумент, то история получается иная. На первом месте будет директория в которой располагается скрипт. А текущая рабочая директория игнорируется. Пишем скрипт с таким содержанием: # script.py import sys for path in sys.path: print(f'"{path}"') Запускаем python3 /home/user/dev/script.py Получаем "/home/user/dev" "/usr/lib/python37.zip" "/usr/lib/python3.7" ... 🔸 Если вы запускаете скрипт по имени модуля то на первом месте будет домашняя директория текущего юзера python3 -m script "/home/user" "/usr/lib/python37.zip" "/usr/lib/python3.7" ... Скрипт должен быть доступен для импорта На что это влияет? На видимость модулей для импорта. Если вы ждёте, что, запустив скрипт по пути, сможете импортировать модули из текущей рабочей директории, то вы ошибаетесь. Придётся добавлять путь os.getcwd() в sys.path самостоятельно или заранее объявлять переменную PYTHONPATH. #basic

Hashtags

Резултати

Пронајдени 2 слични објави

Пребарај: #numa

当前筛选 #numa清除筛选
DOFH - DevOps from hell

@dofh_ru · Post #3851 · 03.09.2025 г., 12:20

Proxmox: привязка CPU к виртуальным машинам Не всегда очевидно, зачем вообще нужна привязка CPU к виртуальным машинам, особенно если речь идёт о небольших развертываниях - там этот параметр чаще всего просто игнорируют. Но в реальном продакшене использование CPU affinity становится действительно важным для повышения производительности виртуалок. https://telegra.ph/Proxmox-privyazka-CPU-k-virtualnym-mashinam-09-03 #ит_статьи#devops#proxmox#linux#numa

DOFH - DevOps from hell

@dofh_ru · Post #3937 · 24.11.2025 г., 06:45

Почему мое приложение на 2 vCPU работает быстрее в виртуалке, чем в контейнере? С ростом популярности Kubernetes и контейнеров многие команды не только разрабатывают и разворачивают новые приложения сразу под Kubernetes, но и переносят туда уже существующие сервисы. Эти сервисы до этого могли работать на bare metal серверах или на виртуальных машинах. Контейнеры реализуют идею «Собрал один раз — запускай где угодно», что позволяет командам разработки и эксплуатации управлять приложениями легче и более системно. Но довольно часто после переноса приложения как есть в Kubernetes производительность вдруг оказывается ниже ожидаемой. Эта заметка в первую очередь смотрит на проблему со стороны CPU: почему при переносе сервисов из VM в мир Kubernetes (контейнеров) могут возникнуть определённые сложности и как они могут привести к просадке в производительности. Внутренние узкие места самого приложения — сетевой ввод-вывод, дисковый ввод-вывод и тому подобное — остаются за рамками обсуждения. https://telegra.ph/Pochemu-moe-prilozhenie-na-2-vCPU-rabotaet-bystree-v-virtualke-chem-v-kontejnere-11-24 #ит_статьи#devops#kubernetes#performance#numa#cgroups#cpulimit