• Почему после компиляции своего ядра linux его размер в разы больше?

    3vi1_0n3
    @3vi1_0n3
    Собирал свежие ядра пару лет под Дебиан, пока поддержку некоторого железа в пакетном не завезли через два релиза, потом перестал. Там очень много непонятного между пакетными ядрами и сборкой из исходников.
    Несколько примеров:
    1. По умолчанию куча новых модулей (не входящих в старые версии) включена. Если использовать конфиг от старого ядра, новые модули может понадобиться отключать руками.
    2. По умолчанию куча модулей для старого железа включена.
    3. Есть шанс, что определенные модули идут в разных пакетах и не входят в дженерик в дистрибутивных сборках, либо исключены совсем. Из сырцов вы получите всё, вообще всё, что есть в исходниках, либо в модулях, либо в основном ядре, если специально не отключать, в том числе кучу старых девайсов, которых у вас скорее всего нет, или платы видеозахвата, которые вам, например, не нужны.
    4. Если хотите собрать ядро поменьше, придется внимательно читать информацию по железу и тратить реально дофига времени на то, чтобы оставить в монолитном куске только то, что нужно, включая все зависимости, остальное либо собирать модулями, либо отключать совсем.
    5. Можно поотключать вообще всё и постепенно включать то, что имеет смысл. Грузиться нормально скорее всего сразу не будет, но по ошибкам обычно можно примерно понять куда копать.

    Разобраться с этим списком быстро не будет. Можно взять конфиг из пакетного ядра, и начать копать от него, в любом случае это вопрос количества попыток, опыта и уровня понимания что там зачем. Scheduler, например. Есть возможность выбрать один из поддерживаемых, но надо знать, что это такое, и различия между ними. Где-то видел
    статью про планировщики, возможно на хабре.

    Я обычно собирал реально только то, что использовал, преемптивное ядро, плюс USB-устройства выборочно (клавы-мыши в монолит, то, что потенциально могу использовать - в модули), плюс поддержку в ядре файловых систем выборочно (одну, которая используется на корневом разделе, в монолит) и так далее. И после успешной загрузки проходил еще несколько раз и смотрел, что я могу еще отключить совсем, чтобы не собирать ненужное. Занимает обычно лютое количество времени, чтобы найти, прочитать и понять что там что, и довести до состояния "только необходимое плюс немного на перспективу". Собственно поэтому бросил этим страдать сразу как дистрибутивное ядро в пакетах проапдейтилось до нужной версии.

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

    Руководства, которое объясняет, что надо, а что не надо, не видел никогда. Скорее всего потому, что всё очень быстро меняется, за полгода в ядро вливают кучу кода. Это было заметно даже во времена версий 2.4/2.6.
    Поэтому make menuconfig и гуглить непонятное.
    Ответ написан
    2 комментария
  • Приложение падает 502?

    @grinat
    Nginx не получает ответа и закрывает скрипт, поскольку срабатывает read_timeout. Решение это либо чтобы фласк слал данные без буферизации, либо хотя бы писал в хедеры что-то регулярно, а затем отправлял файл, либо увеличить таймаут: https://nginx.org/ru/docs/http/ngx_http_proxy_modu...
    Ответ написан
    5 комментариев
  • Приложение падает 502?

    kotomyava
    @kotomyava
    Системный администратор
    Вероятнее всего, 502 у вас потому, что очень долго занят ваш процесс и не принимает в это время подключений.
    Надо либо менять логику работы, либо запускать много процессов, и распределять между ними запросы.

    Если бы проблема была в таймауте при обработке, была бы 504 ошибка. Если в размере данных принимаемых от клиента(за это отвечает client_max_body_size), то 413.
    Ответ написан
    6 комментариев