AA
мне кажется, ты что-то не так делаешь :) 300m...
Size: a a a
2020 May 03
DS
60-80k rps ?
нет, коннектов. rps там 10K
AA
мне 50 хватает за глаза
AA
и то это я грубанул даже... там и 30 хватит
DS
мне кажется, ты что-то не так делаешь :) 300m...
Тестил чательно. 50m shared = в два три раза CPU больше затрачивается при reload. Когда кэша не хватает, полных ssl handshake'ов больше при reload, из-за чего вероятно и сильно росло CPU.
300m избавило от этой проблемы
300m избавило от этой проблемы
S
60-80к конектов не в секунду, а просто висящих? При 10к рпс, что-то много. Если всего, то они же не все вместе придут при reload. Как влияет увеличение до 300m?
AA
мб там cdn
S
В cdn даже коннектов в секунду сильно меньше чем rps.
2020 May 04
АП
Добрый день, товарищи.
На боевом сервере, что мне доверили, в docker-контейнерах крутится следующее: postgres, nginx, gitea, certbot, youtrack, registry, portainer и корпоративное приложение на java.
Все контейнеры описаны в docker-compose, а все тома именованные.
Насколько неправилен следующий алгоритм бэкапа:
- Останавливаю docker, чтобы не велась запись в тома;
- Тарболю /var/lib/docker/volumes/ вместе с docker-compose.yaml;
- Запускаю docker;
- Заливаю полученный тарбол на резервный сервер.
В случае уничтожения основного сервера на резервном распаковываю в /var/lib/docker/volumes тома, запускаю docker-compose up.
Насколько описанный способ самодостаточен, охватывает ли он все нюансы?
Как я понимаю, вопрос резервирования в докере можно разбить на три части: резервирование образов, резервирование контейнеров и резервирование томов и все это можно делать встроенным средствами docker.
Но резервировать образы я не вижу смысла, так как все они есть в docker hub. Смысл резервировать контейнеры тоже не ясен, так как я использую именованные тома и бэкаплю их. Бэкап томов средствами докера выглядит сложнее, чем банальный тарбол.
На боевом сервере, что мне доверили, в docker-контейнерах крутится следующее: postgres, nginx, gitea, certbot, youtrack, registry, portainer и корпоративное приложение на java.
Все контейнеры описаны в docker-compose, а все тома именованные.
Насколько неправилен следующий алгоритм бэкапа:
- Останавливаю docker, чтобы не велась запись в тома;
- Тарболю /var/lib/docker/volumes/ вместе с docker-compose.yaml;
- Запускаю docker;
- Заливаю полученный тарбол на резервный сервер.
В случае уничтожения основного сервера на резервном распаковываю в /var/lib/docker/volumes тома, запускаю docker-compose up.
Насколько описанный способ самодостаточен, охватывает ли он все нюансы?
Как я понимаю, вопрос резервирования в докере можно разбить на три части: резервирование образов, резервирование контейнеров и резервирование томов и все это можно делать встроенным средствами docker.
Но резервировать образы я не вижу смысла, так как все они есть в docker hub. Смысл резервировать контейнеры тоже не ясен, так как я использую именованные тома и бэкаплю их. Бэкап томов средствами докера выглядит сложнее, чем банальный тарбол.
D
Алексей Попов
Добрый день, товарищи.
На боевом сервере, что мне доверили, в docker-контейнерах крутится следующее: postgres, nginx, gitea, certbot, youtrack, registry, portainer и корпоративное приложение на java.
Все контейнеры описаны в docker-compose, а все тома именованные.
Насколько неправилен следующий алгоритм бэкапа:
- Останавливаю docker, чтобы не велась запись в тома;
- Тарболю /var/lib/docker/volumes/ вместе с docker-compose.yaml;
- Запускаю docker;
- Заливаю полученный тарбол на резервный сервер.
В случае уничтожения основного сервера на резервном распаковываю в /var/lib/docker/volumes тома, запускаю docker-compose up.
Насколько описанный способ самодостаточен, охватывает ли он все нюансы?
Как я понимаю, вопрос резервирования в докере можно разбить на три части: резервирование образов, резервирование контейнеров и резервирование томов и все это можно делать встроенным средствами docker.
Но резервировать образы я не вижу смысла, так как все они есть в docker hub. Смысл резервировать контейнеры тоже не ясен, так как я использую именованные тома и бэкаплю их. Бэкап томов средствами докера выглядит сложнее, чем банальный тарбол.
На боевом сервере, что мне доверили, в docker-контейнерах крутится следующее: postgres, nginx, gitea, certbot, youtrack, registry, portainer и корпоративное приложение на java.
Все контейнеры описаны в docker-compose, а все тома именованные.
Насколько неправилен следующий алгоритм бэкапа:
- Останавливаю docker, чтобы не велась запись в тома;
- Тарболю /var/lib/docker/volumes/ вместе с docker-compose.yaml;
- Запускаю docker;
- Заливаю полученный тарбол на резервный сервер.
В случае уничтожения основного сервера на резервном распаковываю в /var/lib/docker/volumes тома, запускаю docker-compose up.
Насколько описанный способ самодостаточен, охватывает ли он все нюансы?
Как я понимаю, вопрос резервирования в докере можно разбить на три части: резервирование образов, резервирование контейнеров и резервирование томов и все это можно делать встроенным средствами docker.
Но резервировать образы я не вижу смысла, так как все они есть в docker hub. Смысл резервировать контейнеры тоже не ясен, так как я использую именованные тома и бэкаплю их. Бэкап томов средствами докера выглядит сложнее, чем банальный тарбол.
для докера есть https://t.me/docker_ru, но звучит коряво в целом. Там же и так есть слои
АП
для докера есть https://t.me/docker_ru, но звучит коряво в целом. Там же и так есть слои
Спасибо.
OT
OR
Ребята привет как бы вы синхронизировали дев сервер з продакшеном
OR
как это правильно сделать
OR
)
PG
накатить идентичную пакетную базу
сделать дамп продакшн БД, сделать ее обезличивание и залить дамп на дев
сделать дамп продакшн БД, сделать ее обезличивание и залить дамп на дев
AS
Ребята привет как бы вы синхронизировали дев сервер з продакшеном
а что именно синхронизировать? код? данные? зачем?
OR
код и данные. так надо :\