fokin_nikolay1989, а в связи с чем вообще вся эта затея? Если из-за неправильного массового chmod, то лучше не надеяться на чудо, а переставить систему, всё равно проблемы будут постоянно где-нить вылазить.
Drno, рекомендую поизучать, какие сигналы и какому процессу посылаются при закрытии этого терминала. Потом можно попробовать написать скрипт с командой trap, которая перехватывает сигналы в bash. Возможно, там посылается SIGTERM, который до openvpn через su уже не добирается.
Смотреть правильнее не на free а на available. Это, грубо говоря, сколько потенциально есть свободной памяти, если весь кэш скинуть (это неточное определение!).
Если памяти приложениями используется мало, то кэш постепенно может занять практически всю свободную память и это более чем норма - ведь это означает более высокую скорость к данным. В некоторых сценариях использования это даже нарочно так делают: заводят много памяти, чтобы в кэше лежало значительная часть дисковых данных. Это хорошо, например, для баз данных и вообще для часто интенсивно и повтороно читаемых данных любого вида.
Совсем до нуля кэш сбрасывать нельзя, потому что многое будет ощутимо "тормозить". Поэтому система всегда начинает выносить часть страниц из памяти в swap ещё до исчерпания памяти. Этим в значительной степени управляет параметр vm.swappiness. Чем он ниже, тем менее охотно системой используется swap. Но при этом в типичной "домашней" системе использование swap это даже хорошо, потому что некоторые приложения (типа браузера) охотно выделяют память, которая им нужна довольно редко. Например, если открыть много вкладок в браузере, то будет выделено прилично памяти, но если на эти вкладки не переключаться, она спокойно уедет в swap и будет там лежать до востребования.
Это некоторые общие моменты, чтобы было более понятно, как это всё работает. На самом деле управление памятью в ядре Linux крайне сложно устроено. Говорят, даже среди разработчиков ядра единицы его понимают более-менее полностью. А всё ради того, чтобы эти механизмы качественно или хотя бы приемлемо работали в самых разных сенариях.
veroni1337, битрикс часто так настроен, что ошибку 404 обрабатывает файл 404.php, который подключает ядро битрикса. Поискать в конфигах как 404 обрабатывается. Например, это может быть в Apache:
ErrorDocument 404 /404.php
Самое простое - в 404.php сделать в самом начале exit, чтобы сразу отлупал.
У меня был кейс, когда сайт на битриксе жутко лагал. Я в итоге нашёл, что на главной сделали карусельку из баннеров когда-то давно, а потом баннеры удалили. В итоге каруселька у пользователей крутила картинки часто и много, а 404 от них хорошо так грузили сервер. Я наскоро сделал в конфиге веб-сервера, чтобы отсутствующие картинки (*.jpg, *.png итд) по 404 выдавали пустой 404fast.php а не 404.php, и всё нормализовалось. Ну дальше отправил владельцев сайта карусельку-то убирать или исправлять.
sanya1995, для начала попробовать собрать без докера. Записать все команды, которые понадобились, и нужне зависимости (ну там компилятор, библиотеки с dev-пакетами...). Потом начать повторять то же самое в Dockerfile. С учётом разницы в именованиях пакетов итд итп.
Другой путь - освоить сборку пакетов под alpine и доработать имеющиеся манифесты пакетов alpine под свои нужды.
Никто не делает видео или готового кода для подобного. Это нужно крайне редко, довольно сложно и как правило делается людьми, которые достаточно подкованы для самостоятельного решения подобных задач.
В данном же случае настоятельно рекомендую делать образ на базе ubuntu, а не alpine, поскольку там все нужные модули уже включены в стандартную пакетную базу. Необходимость alpine в докер-образах - миф. В принципе, ничто не мешает использовать разные базовые системы в разных образах, под каждое приложение ту систему, к которой оно лучше адаптировано или где проще и быстрее достичь нужного результата.
У сбера во многих вкладах в условиях указано, что если он закрывается досрочно, то применяется ставка 0.01%. Видимо, это борьба с неполным месяцем при начислении процентов.
theurus, sqlite - это не полноценная база данных, а жалкое подобие, которое используют тогда, когда полноценную базу поднять неудобно. Однако для полноценного онлайн-сервиса с нормальной аудиторией это даже рассматривать неприлично. Не потому что упрётся или не упрётся. А потому что так приличный сервис можно реализовать только от отчаянья.
У нас использовали JIRA, но из-за лицензирования per user стало очень неудобно. Поэтому офисный саппорт перевели на GPLI. Я не в курсе, насколько он хорош, но заявки по почте создаются успешно. Хотя, конечно GPLI изначально для инвентаризации ставили. LDAP вроде умеет.
pfg21, в этом "бизнесе" словом CDN обозначают не CDN в настоящем профессиональном смысле, а просто пиратский видеосервис где-нить в абузоустойчивой локации без цели быть близко и отзывчиво к потребителю, который живёт на рекламу xxxbet'а :) Вопросов эффективной доставки качественного контента такие "CDN" не решают вообще. В кодике сериалы аниме кладут 24-минутные серии 720p с размером серии 194 Мб (битрейт 1000 для видео avc и 90 для аудио aac), очень хорошо экономят, ведь их типичный потребитель на качество вообще не обращает внимание...
NovaVortex, я тоже могу смотреть видео без рекламы на телефоне, но вот штатный адблок в samsung browser с рекламой кодика в какой-то момент перестал справляться. Далеко не все пользователи способны на телефоне с этим справиться. В любом случае, за такую рекламу продолжают платить, а видеосервисы как-то продолжают существовать, значит, зрителей у рекламы хватает...
AptRoApt, ну как бы ts и предназначен для того, чтобы видео без индексирования можно было бы и смотреть с любого места онлайн, и перематывать. С такими видео и в плеерах бывают проблемы. С полноценно проиндексированным видеофайлом не сравнится.
wannaluv, если это Firefox то он в Ubuntu сейчас установлен через snap и это иногда доставляет проблем, хотя так чтобы файлы совсем были недоступны это не вполне нормально для него. Можно snap-версию совсем удалить и установить сборку от Mozilla Team отсюда https://launchpad.net/~mozillateam/+archive/ubuntu/ppa. Но все настройки потеряются (или придётся руками их перекладывать из snap-версии в стандартное размещение обычного Firefox).
NovaVortex, если речь идёт о пиратских CDN типа кодика, которые по недоразумению называют "балансерами" (на самом деле "балансер" это совсем не про это), то у них обычно за это развлечение говённая реклама пихается (нормальный адблок, конечно, режет, но многие смотрят из мобильных браузеров, где адблок или отсутствует, или очень слабый, легко обходимый).
Ещё одним недостатком этих "балансеров" является то, что они обычно очень существенно жмут видео. Вплоть до использования статического битрейта. Результат не всегда хорош, но большинство пользователей такого контента качество видео обычно парит ещё меньше, чем поганая реклама.
Собственно, CDN в таких "кинотеатрах" не геораспределённые (и даже скорее "далёкие" от потребителя, ибо пиратство лучше всего работает из-за пределов страны обитания получателей), там задача в другом совсем. Дело в том, что проблема даже не в занимаемом видеофайлами месте. В первую очередь проблема в пропускной способности канала. Например, пусть у нас видеофайлы с битрейтом 3 Мбит/с (аудио+видео), тогда 300 пользователей забьют условный гигабит. Популярному "кинотеатру" придётся иметь много серверов, которые будут отдавать одно и то же. То есть на деле места нужно будет очень и очень много, причём оно уйдёт на дублирование файлов.
Память в этих серверах будет совсем не узким местом.
Помимо всего прочего, придётся очень много усилий потратить на менеджмент этого хозяйства, например, на динамическое принятие решений о количестве реплик каждого (популярный свежий фильм надо хранить во множестве копий, в то время как малопопулярный можно хранить не так широко).
А ещё быстро вылезет проблема качальщиков и "онлайн-кинотеатров" из всяких телеграмов, которые будут качать на максимальной скорости фильмы с твоего сайта и выкладывать в свои каналы/боты, забивая сеть. Придётся напрячься с управлением скоростью отдачи, чтобы это не работало. Например, кодик по факту отдаёт видео на скорости максимум 2x от выбранного качества (видимо, по имени файла в ссылке, содержащей разрешение, определяется лимит скорости в вебсервере). Скачать что-то штучное ещё можно, поставить скачивание на промышленный поток уже не получится, ведь в телеграм-ботах мало кто будет ждать доставки "заказанного" файла несколько часов.
Сколько это стоит для таких сервисов сложно сказать. Но, скорее всего, они не используют виртуалки. Для больших дисковых пространств выгоднее или арендовать железные сервера, или даже ставить своё оборудование в датацентр. Причём для серверов отдачи видео не нужно много процессора и памяти, можно брать дешманские б/у сервера, цеплять к ним дисковые полки (в том числе с недорогими б/у дисками) и получить очень даже неплохой по цене вариант.
Да и в целом не так уж и дорого хранить десятки террабайт. Я себе в прошлом году в розницу купил не самые дешёвые диски по цене 2700 рублей за террабайт, а ведь оптом, да ещё и линейку и производителя подешевле - можно наверное и на 1000 за террабайт выйти... При большой активности пользователей и платящих рекламодателях можно очень даже неплохо зарабатывать.
Хранить файлы в базе с самого начала была так себе затея.
Нормально хранить в S3 (как стороннем, так и самостоятельно поднятым. Легко масштабировать - поднимаем ещё один инстанс, другого поставщика итдитп. В базе храним ссылку на файл. Можно регорганизовать сервис так, что он будет отдавать клиентскому приложению presigned url на файл ограниченного срока действия (например, 5 минут), чтобы утекание ссылки не создавало больших рисков. Так как контент отдаваемого файла при этом не прокачивается через бэкенд, можно избежать лишней нагрузки на своё приложение. И база не страдает, потому что извлечь ссылку на файл можно быстро.
Но это необязательно, можно и просто на диске. Но не в базе.
