81 lines
5.5 KiB
Markdown
81 lines
5.5 KiB
Markdown
---
|
||
aliases:
|
||
tags:
|
||
- maturity/🌱
|
||
- content/problem
|
||
date: 2025-02-04
|
||
---
|
||
В какой-то момент я обнаружил, что мой сервер (Процессор: 2 core Память: 4 Gb Хранилище: 60 Gb) на котором запущена Gitea стал потреблять много ресурсов.
|
||
|
||
```
|
||
top -o %CPU -b -n 1 | head -20
|
||
```
|
||
|
||
Cудя по top, основным потребителем CPU является Gitea, которая занимает 22,7% CPU и использует 61,6% оперативной памяти. Также увидел несколько активных процессов git, которые могут быть вызваны Gitea для обработки репозиториев, и они тоже нагружают CPU.
|
||
|
||
Следующим шагом я проверил логи контейнера
|
||
|
||
```
|
||
docker logs --tail 50 gitea
|
||
```
|
||
|
||
По логам увидел, что у меня много **медленных запросов (slow GET)**, связанных с:
|
||
1. Обработкой коммитов и blame (история изменений файлов)
|
||
2. Доступом к файлам в репозиториях
|
||
3. Работой с RSS и raw-файлами
|
||
4. Запросами на поиск и скачивание контента
|
||
|
||
Кроме того, встречались 404-ошибки, которые могут указывать на частые обращения к несуществующим ресурсам.
|
||
|
||
Далее я проверил активные процессы Gitea
|
||
|
||
```
|
||
docker exec -it gitea top -b -n 1
|
||
```
|
||
|
||
Gitea активно выполняла много процессов Git, связанных с read-tree, rev-list, cat-file, check-attr и batch-check. Это говорило о том, что Gitea либо индексирует файлы, либо выполняет операции, связанные с доступом к репозиториям:
|
||
- read-tree → Чтение структуры репозитория.
|
||
- log -1 → Получение последнего коммита для файла.
|
||
- cat-file --batch → Доступ к содержимому файлов.
|
||
|
||
Это может быть вызвано:
|
||
1. [[Фоновые задачи Gitea|Фоновыми задачи Gitea]].
|
||
2. **Запросами от пользователей** — если кто-то активно использует Gitea через UI. Но у меня персональный Git хостинг, никто кроме меня им не пользуется.
|
||
3. **Запросы от ботов** - какие-нибудь парсеры, особенно если пользователей в Gitea не много.
|
||
4. **Webhooks или интеграциями** — если какие-то сервисы взаимодействуют с Gitea. Интеграция у меня была только с Drone CI, которая вряд ли может создавать такую нагрузку.
|
||
|
||
|
||
|
||
Перед дальнейшими действиям, я решил провести [[Автоматическая диагностика в Gitea|самодиагностику Gitea]]. Но все проверки были успешно пройдены.
|
||
## Отключение переодических задач
|
||
Я решил, что проблема в [[Фоновые задачи Gitea|фоновых задачах Gitea]]. Тем более, что у меня было много репозиториев зеркал, которые стягивались с GitHub. Так что мой следующий шаг: Проверить фоновые задачи в Gitea. Это можно сделать или запросом, или через панель управления в UI.
|
||
|
||
```
|
||
curl -X GET "http://localhost:3000/api/v1/admin/cron" -H "Authorization: token YOUR_ACCESS_TOKEN"
|
||
```
|
||
|
||
Далее я отключил сначала все фоновые задачи и оставил только важные. И на первый взгляд показалось, что это помогло.
|
||
|
||
Однако спустя час Gitea снова потребляла CPU (41,2%) и память (13,7%). Кроме того, снова был запущен процесс git (17,6% CPU), что говорило о том, что Gitea выполняет какие-то операции с репозиториями. Хотя пользователей в это время не было.
|
||
## Запросы от ботов
|
||
Как я уже говорил это мой персональный публичный Git хостинг, так что им пользуюсь только я. Но он публичный, и я предположил, что возможно какие-то парсеры могут постоянно сканировать репозитории, например в надежде получить какие-нибудь случайно опубликованные ключи доступа.
|
||
|
||
Я решил проверить эту гипотезу.
|
||
|
||
|
||
|
||
|
||
***
|
||
## Мета информация
|
||
**Область**:: [[../../../meta/zero/00 Gitea|00 Gitea]]
|
||
**Родитель**::
|
||
**Источник**::
|
||
**Создана**:: [[2025-02-04]]
|
||
**Автор**::
|
||
### Дополнительные материалы
|
||
-
|
||
|
||
### Дочерние заметки
|
||
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
||
|