Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

Мы кажется не понимаем друг друга.

Мне тоже так кажется.

shared_buffers это не общий размер кэша, это размер окна памяти который постгрес может расшарить между внутренними процессами вызвав mmap.

shared_buffers настройка в PostgreSQL указывает размер всего буфера, что может использовать PostgreSQL инстанс. Про «окно» я не понял, и возможно, не знаю что с ними.

Объем shared_buffers имеет техническое ограничение в связи с механизмом выделения такой памяти ядром.

Возможно мы о разном говорим, но как я знаю, каждый процесс на 32 битной машине лимитирован в 4ГБ адресного пространства, где хотя бы 1ГБ (в Линуксе) зарезервирован ядром. Это означает, что не зависимо, сколько на машине памяти, каждый PostgreSQL инстанс сможет обратится максимум к 3ГБ памяти. Тоесть максимум для shared_buffers — 2-2.5ГБ. Но на 64 битах нет такого ограничения.

Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

А какие данные еще вы имеете ввиду, кроме размера базы (таблицы + индексы), которые будут в shared_buffers? Размер базы в shared_buffer как я и писал раньше, зачем больше?

Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

А почему вы привязываете параметр глобального кэширования рабочих данных кластера, к объему базы. Баз, например, может быть несколько.

Может, но в проектах с высокой нагрузкой в основном работа идет с одной базой. Для шаред хостинга схема тюнинга совсем другая.

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

Основное предназначение shared_buffers — кэш блоков таблиц и индексов. Чем большая часть данных там лежит, тем лучше для операций чтения. По поводу 25% можно даже найти на официальной документации — www.postgresql.org/docs/devel/static/runtime-config-resource.html

Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

Вы идете от системы, а я иду от памяти. Я не говорю процент от всей системной памяти. На сервере может быть 2Гб памяти, но базе я могу выделить только 1Гб, а значит 25-30% идут от этого числа. shared_memory на 32 битных системах можно поднять до 2.5-3Гб (но не нужно), а на 64 битных нет предела (достаточно большой).

Плюс, почему вы пишете что зависит от базы, если емнип это настройка на уровне кластера.

shared_memory в первую очередь используется для данных, с которыми активно ведется работа. Если база помещается в 50% памяти, то выделив 50% под shared_memory может дать хорошую производительность для базы.

Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

128mb стандартный минимум для *nix

Если базе выделять в сумме 512mb. Вообще данная утилита для простейшей настройки — pgtune.leopard.in.ua/ Брать 1/4 для shared_buffers было установленно давно через практическое применение. Понятное дело, что иногда нужно и 80% памяти давать, зависит от размера базы и метода её использования.

Работа с PostgreSQL: настройка и масштабирование (4-е издание) и Cooking Infrastructure by Chef (1-е издание)

Не за что!

Использование Faye вместе с SSL

upstream prodfaye {
  server 127.0.0.1:9292 weight=1 fail_timeout=30s;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {

...

  location /faye {
       proxy_pass http://prodfaye;
       proxy_http_version 1.1;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection $connection_upgrade;
       proxy_buffering off;
       proxy_redirect off;
       proxy_connect_timeout      90;
       proxy_send_timeout         90;
       proxy_read_timeout         90;
       proxy_set_header X-Forwarded-Proto https;
       break;
    }

}

Работает, ssl не активируется на faye. HTTP терминируется через Nginx.

Голливуду запрещают печатать фальшивые доллары

они изготовили купюры с надписью “In Dog We Trust” вместо оригинальной надписи “In Goв We Trust”

«In God We Trust» на оригинальной

5 практических примеров для изучения фреймворка React

Но если статья не верная, то зачем её переводить? Возмите за основу оригинал и переработайте. Мы вроде тут оцениваем не качество перевода, а ценность материала статьи.

5 практических примеров для изучения фреймворка React

Если большинство называет Java как «Ява», то это значит, что Jazz теперь называется «Язь» :)

P.S. Большинство, которое не читает официальную документацию?

5 практических примеров для изучения фреймворка React

Я понимаю, что это перевод, но как можно называть библиотеку фреймворком? В документации все четко расписано:

React is a JavaScript library for creating user interfaces by Facebook and Instagram. Many people choose to think of React as the V in MVC.

Поэтому сравнивать его с Angular.js и Ember.js уже не верно. Это все равно, что написать, что jQuery как фреймворк проще, чем Angular.js и Ember.js :)

Отладка электронной почты при помощи MailCatcher

3-я вкладка позволит нам использовать Fractal для анализа содержимого письма. Её я пропущу, т.к. это немного выходит за рамки сегодняшней статьи.

Вкладка вроде уже не работает, так как сервис не рабочий.

Для того, что бы ничего не ставить можно просто воспользоватся mailtrap.io. В нем есть еще анализ письма на спам, блеклист списки и таже проверка css (если в письме есть HTML).

Также не так давно на хабре была статья про debugmail.io — habrahabr.ru/post/217201/ В нем нет плюшек с анализом письма, но «акцент на совместную работу» есть.

Генератор гамм на Reactjs

javascript framework от facebook — Reactjs

Это не фреймворк. Это только View layer.

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

Я думал добавить поля, для указания SSD или нет, какой размер базы, прочее. Но у меня нет данных по разным таким случаям и какая настройка давала выигрыш для PostgreSQL. Потому что по таким данным нужно создать математическую модель (если её еще нет) и добавить в pgtune. Ведь все, что делает он — считает по формулам по указаным условиям :)

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

habrahabr.ru/post/217073/#comment_7438801

Я ничего никому не навязываю. Право человека использовать данную утилиту или нет :)

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

Что бы не выдумывать вот цитата из рассылки по поводу shared_buffers:

* Shared buffers must (currently) compete with OS inode caches. If this is shared buffers are too high, much of the cached data is already cached by the operating system, and you end up with wasted RAM.
* Checkpoints must commit dirty shared buffers to disk. The larger this is, the more risk you have when checkpoints come, up to and including an unresponsive database. Writing to disks isn't free, and sadly this is still on the slower side unless all of your storage is SSD-based. You don't want to set this too much higher than your disk write cache.
* Performance gains taper off quickly. Most DBAs don't see gains after 4GB, and fewer still see any gains above 8GB. We have ours set at 4GB after a lot of TPS and risk analysis.
* Since shared_buffers is the amount of memory that could potentially remain uncommitted to data files, the larger this is, the longer crash recovery can take. Having this too high could mean the difference between a five-minute outage, and a five-second outage. The checkpoint_* settings control how this is distributed and maintained, but the risk starts here.

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

Тут проблема не только с процессорами. Checkpoint операция должна сбрасывать данные с shared_buffer на диск. Тоесть чем больше у Вас shared_buffer, тем больше он может содержатся обьем измененных данных в памяти в PostgreSQL (худший вариант — весь shared_buffer содержит измененные данные), который потребует их сбросить на диск. И чем дольше этот обьем будет записываться на диск, тем дольше у Вас будет находится база, что не отвечает не на один запрос (в худшем случае).

Debug Mail — простой в использовании smtp-сервер для разработчиков

Это аналог mailtrap.io/?

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

Долго искать не нужно — первая строка в приведенной цитате из блог поста в Вашем коментарии. Сейчас я пока вернул расчет на 1/4 RAM, поскольку не вижу лимитов в исходном коде базы на 8Гб.

PgTune — настройка производительности PostgreSQL для заданной аппаратной конфигурации (онлайн версия)

В данном куске из статьи написано тоже самое, что высказал и я в коментарии — в основном 8ГБ пишут что это максимально, но некоторые заявляют, что если ставить больше — увеличивается производительность.