открыл htop и теперь мне страшно

ребят, наверно тупой вопрос, но я не понимаю куда смотреть.

сижу на обеде, зашёл по ssh на свой сервер просто проверить что живой. самый маленький тариф, там у меня туннель для телефона и пара мелочей. тут кто-то писал что htop удобнее top, ну я поставил, запустил.

и теперь сижу над ним как над египетскими иероглифами) сверху load average: 0.87 0.54 0.31. ядро одно, значит 0.87 это почти потолок? или наоборот норм? память закрашена где-то до середины, swap пустой.

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

как отличить «это нормальная загрузка» от «пора волноваться»? есть одна цифра за которой смотреть, или оно всё вместе считается?

kirill_nsk 0.87 на одном ядре — это не потолок и не проценты. это длина очереди: в среднем чуть меньше одного процесса ждёт процессор. волноваться начинаешь, когда стабильно выше числа ядер и растёт. по твоим цифрам серверу скорее скучно, чем страшно.

одной волшебной цифры нет, смотри так. в htop жми F6 и сортируй по CPU% — кто сверху, тот и грузит. потом:

vmstat 1 5

колонка wa: почти ноль — всё норм, двузначная — упираешься в диск, а не в процессор. load растёт и от диска тоже, это не только cpu.

lexa92, за wa спасибо, проверил — ноль, можно не спать дальше) а страшно не 0.87, kirill_nsk. страшно когда жмёшь F6, а сверху процесс, которого ты не запускал

lexa92, блин, спасибо, отпустило)) сегодня с утра до работы сел и всё по твоему списку проверил.

vmstat прогнал — wa нули во всех пяти строках. по F6 отсортировал, и тут смешно вышло: на первом месте сам htop с его 3%)) то есть сервер грузит в основном моя собственная паника. ниже wireguard с нулём и мой маленький node-бот, тоже около нуля.

и про очередь понял наконец: 0.87 это не «87 процентов загрузки», а типа один процесс ждёт своей очереди. я вчера чуть не пошёл тариф менять из-за этого числа 🤦 хорошо что сначала спросил.

void_3am, список процессов весь проглядел — вроде всё своё, чужого не нашёл. но там куча штук в квадратных скобках типа kworker, я их точно не запускал. гугл говорит что это системные и так надо, это правда они? а то теперь я на каждый процесс смотрю с подозрением)

kirill_nsk писал:
сервер грузит в основном моя собственная паника

вот это я себе на стикер перепишу, потому что это буквально про меня))

Про процессы в квадратных скобках — я этим же пугалась. Когда у клиента лёг сайт, я открыла список процессов, а там этих kworker штук двадцать. У меня всё, паника, взломали. Племяннику в телеграм с восклицательными знаками, он с вахты ответил одной строкой: всё что в квадратных скобках — это сам линукс, он так дышит, не трогай)) Гугл тебе правду сказал, это системные.

И с цифрами история похожая была. На одном клиентском сайте полоса памяти закрашена почти доверху — я уже прикидывала переезд на тариф дороже. Оказалось, линукс просто забивает свободную память кэшем «на всякий случай» и отдаёт, когда реально понадобится. Сайт жив до сих пор, а я чуть не заплатила за собственную нервозность 🤦

Теперь у меня главный индикатор простой: сайты открываются, клиенты в вотсап не пишут — значит серверу норм, независимо от того, что там закрашено)) А в цифры лезу только когда уже что-то болит.

olya_web с индикатором «клиенты не пишут в вотсап» есть одна проблема: клиенты замечают последними. сайт может полчаса отдавать 502, пока кто-то из них вообще зайдёт, и ещё столько же, пока тебе напишут. узнаёшь о падении через час после того, как оно случилось. для визитки терпимо, для магазина это уже деньги. цифры как раз надо смотреть не когда заболело, а чтобы не заболело.

по памяти. то, что ты описала про кэш, — правда, но смотреть это надо не по полоске в htop, а так:

free -h

колонка free будет маленькой всегда, на неё не смотри. смотри на available — это сколько памяти реально можно взять под программы прямо сейчас, с учётом того, что кэш отдаст. если available половина от total — памяти у тебя вдвое больше, чем кажется по закрашенной полосе, и переезд был бы зря.

минимум, чтобы не узнавать о проблемах из вотсапа:
1. раз в день глазами:

df -h

диск, забитый под сотню, кладёт сайты чаще любой нагрузки. логи растут молча, потом резко.
2. там же:

uptime

третье число — load за 15 минут. стабильно выше числа ядер — уже разбираешься, кто грузит.
3. если всё-таки лёг, первое действие:

journalctl -u nginx -n 50 --no-pager

или имя твоего сервиса вместо nginx. последние 50 строк лога, там почти всегда написано, почему умер. быстрее, чем гадать по htop.

и раз тема зашла: подозрительный процесс проверяется так:

ls -l /proc/1234/exe

где 1234 — pid. у обычного процесса там путь к файлу на диске. у kworker и прочих в квадратных скобках файла нет вообще, они живут в ядре. племянник прав, это система дышит.

kirill_nsk тебя пункт про df тоже касается. на 40 гигах диск кончается раньше, чем ты успеваешь привыкнуть к серверу.

kirill_nsk kworker — это линукс дышит, да. чужой процесс выглядит обычно скучнее: что-нибудь вроде kworker_miner из /tmp) а раз сверху твой же htop и wa нули — спи, сервер уже спит

lexa92, добрался до free -h в обед. available 1.3 гига из двух, хотя полоска закрашена наполовину. то есть и память мне тоже приснилась 🤦 df показал диск занят на треть. выходит сервер у меня здоровее меня самого))

только вопрос: journalctl -u nginx это если nginx стоит? у меня его вроде нет, у меня туннель и один бот на ноде. мне что вместо nginx подставлять если чё?

kirill_nsk, подставляй имя своего сервиса: journalctl -u mybot (или как ты его в systemd назвал). а для туннеля -u wg-quick@wg0. у меня бот тоже на ноде, так и смотрю)

ivan_tver только сервис не называй mybot. у меня так test_final живёт второй год, и я его уже боюсь перезапускать. а wg-quick@wg0 — единственное имя в systemd, которое выглядит как пароль)

kirill_nsk имена сервисов не гадают, система сама скажет:

systemctl list-units --type=service --state=running

там будет и твой бот, и wg-quick@wg0. дальше journalctl -u имя из первой колонки.

и да, kworker — это ядро, их не трогают вообще. чужое выглядит иначе: живёт в /tmp, имя из случайных букв, жрёт cpu. у тебя такого нет. сервер действительно здоровее тебя, и это без иронии.

lexa92, сделал в обед, всё нашлось. только выяснилось что бот у меня зовётся bot2.service — потому что первый я сломал ночью и просто накатил второй рядом) и первый там же в списке висит, dead, как памятник. его можно снести как-то или пусть лежит?

и дошло наконец: -u это не «логи именно nginx», а просто имя из этого списка. я думал journalctl умеет только nginx читать 🤦 void_3am, твой test_final мне теперь как родной, у меня таких полсистемы наверно)

kirill_nsk писал:
его можно снести как-то или пусть лежит?

сносить. dead-юнит со старым токеном внутри — не памятник, а ключ под ковриком. disable, rm юнит, daemon-reload.

kirill_nsk сноси, n1kita дело говорит. dead-юнит не памятник, он ещё и в логи мусорит при каждой перезагрузке. порядок такой:

sudo systemctl disable bot.service
sudo rm /etc/systemd/system/bot.service
sudo systemctl daemon-reload
sudo systemctl reset-failed

последнее чтобы он перестал висеть в list-units как failed, если где-то остался.

перед rm сделай одну вещь:

grep -i token /etc/systemd/system/bot.service

если токен первого бота лежит там открытым текстом — удаление файла его не убивает, он всё ещё валидный. иди к @BotFather, /revoke, и пусть ключ сгинет. раз бота ты всё равно похоронил, токен от него тоже не нужен.

про -u: да, journalctl читает вообще всё, а -u просто фильтр по имени юнита. удобно так:

journalctl -u bot2 -f

-f это как tail, лог ползёт живьём. очень помогает, когда бот опять «работает, но не отвечает».

и следующего назови сразу bot2_final, пусть у void_3am будет родственная душа.

lexa92 писал:
удаление файла его не убивает, он всё ещё валидный

вот это место обычно и пропускают: файл стёр — в голове чисто, а токен тем временем живой. revoke у @BotFather минута делов. и новый токен лучше сразу в отдельный env-файл, а не в сам юнит, чтобы при следующем «накатил второй рядом» ключи не размножались по системе)

daniyar_ala писал:
файл стёр — в голове чисто, а токен тем временем живой

Это ведь не только про сервера. У нас так люди «увольняются»: человек ушёл, а его учётка в таск-трекере и доступ к таблице живут дальше, потому что «потом отключим». Потом наступает примерно через год, когда уже никто не помнит, зачем эта учётка вообще была.

Поэтому завёл правило: в конце задачи есть пункт «закрыть доступы», как тут у kirill_nsk теперь revoke у BotFather. Пока пункт не отмечен, задача не закрыта, даже если всё работает. Бухгалтерия так документы закрывает — подписано, оплачено, сошлось. Логика та же, только у доступов акта никто не подписывает, поэтому они и протекают)

Про env-файл согласен, а вот до общего хранилища секретов пока не дорос, держу по проектам. Понимаю, что компромисс. Зато при очередном «накатил второй рядом» страдает один проект, а не всё скопом.

ruslan_krd, у меня твой пункт «закрыть доступы» отзывается прямо в работу: я эти доступы и раздаю, и забираю. Когда сдаю сайт клиенту, последний пункт чек-листа — завести человеку админку на его почту и удалить свою учётку. Появился он не из умных книг, а после того, как я пару раз находила себя админом сайтов, которые сдала годы назад. Сидишь в чужой админке как призрак, понимаешь, что можешь всё уронить одной кнопкой, и тихо выпиливаешь саму себя)

А обратная сторона хуже. Не раз приносили сайт «от прошлого разработчика»: захожу в пользователи, а там он один, админ, почта его, и восстановление пароля улетает к нему. Клиент годами платит за сайт, ключи от которого физически у другого человека. В таких случаях я ничего не трогаю, пока не заведём учётку на почту клиента и не поменяем пароли от хостинга — иначе выходит, что я чиню сайт, владельцем которого клиент только числится.

Так что протекает это в обе стороны: чужие доступы у тебя и твои у чужих. К твоему пункту в трекере я бы добавила зеркальный — на старте задачи посмотреть, кто лишний уже внутри.

ruslan_krd, у твоего пункта есть встречная сторона для подрядчика: самому напомнить, чтобы тебя отключили. я в конце проекта пишу клиенту «доступы можно гасить» — чтобы через год не висеть лишней учёткой в чужой системе. но сам не без греха: в ssh-конфиге до сих пор лежит хост проекта, умершего года два назад. удалить рука не поднимается — вдруг воскреснет)

daniyar_ala писал:
удалить рука не поднимается — вдруг воскреснет

да и пусть лежит, ssh-хост денег не просит. у меня в конфиге тоже пара мёртвых, я их считаю не доступами, а фотоальбомом)

дороже обходится то же «вдруг вернёмся» там, где деньги. когда мы сайт переводили с одной оплаты на другую, старый кабинет я не закрыл — вдруг вернёмся, там же всё настроено. не вернулись, конечно, а кабинет жил: карта привязана, пакет смс-оповещений списывается, ключи на возвраты рабочие. заметил не из безопасности, а когда сел сводить квартал и увидел списания, которым в бюджете места нет. сумма смешная, факт неприятный: мёртвый доступ не просто лежит, он ещё и счета выставляет.

поэтому к пункту ruslan_krd «закрыть доступы» у меня прибавился второй: «закрыть кабинет и отвязать карту». пока оба не отмечены, переезд не закончен. а хост в ssh-конфиге из умершего проекта молчит и ничего не хочет — такого можно и пожалеть.