Это надо положить в цитаты и показывать всем, кто хочет построить еще один забор :)

в 99% тупняк базы в aws связан с диском. смотрите avg queue length, ops per second на дискев моменты тормозов. можно просто во встроенных графиках амазона.

у вас база и лог на разные диски разнесены? а база - в одном файле?

ps. у амазона нечестный burst i/o не закладывайтесь на него.

да, уже их и смотрели после iops, после того, как подняли iops, queue length ушёл на диапазон 0-2, я так понимаю, что это норма? настроим на него alarm, чтобы сразу понимать, если начинаются проблемы.

у вас база и лог на разные диски разнесены? — не уверен, у нас в RDS один диск, но вообще я не совсем понял вопрос)
а база - в одном файле? — тоже не понял вопрос.

но в целом у нас стандартный конфиг RDS.

спасибо за советы))

А что вы можете сказать про аврору?

@SergeAx Вопрос про SublimeMerge на хабре к вашей статье - а что под патч коммитами подразумевается ? Если просто построчно диффы в staging складывать - то да, SM умеет все file\hunk\line

на тему rebase —interactive - в sublime merge он не совсем такой же как в гите, они сейчас это делают как сброс бранча без изменения working dir - так что все коммиты можно заново переформировать. Это не так удобно как традиционный гитовый ri, но в общем - тоже пойдет для маленьких PR

Интересно читать что разные команды потихоньку приходят к тому, что база гита это не "священная корова" и если делать умеючи - можно ее крошить и пересобирать так как нужно разработчикам. У меня в разных командах  мы уже давно делаем rebase interactive и squash commits. У начитавшихся gitflow это вызывает обычно содрогания и панику, но как показала практика - если в руках острый нож типа git - лучше уметь и практиковаться в "запрещенных" приемах над репозиториями, чем потом бегать по stackoverflow выискивая - как починить базу. Хотя через некоторое время - пришел к выводу что история никому не нужна, ну она просто нерелевантна реальности, в реальности unit of change у команды - pull request, там и обсуждение, там и описание и баг и все детали. А то как пришли к PR - мало кому интересно, ну если только в blame посмотреть. Так что, я бы согласился с первым комментатором к посту (ага, heresy :D) - он когда спилил мушку, написал вполне дельную вещь - обучение пользованию инструментом  и разумные ограничительные меры > > набора команд и правил.

наши ограничения например очень простые - в мастер все попадает только через PR/MR, все что так вливается - squash, у каждого PR должно быть нормальное описание которое становится комментарием коммита (в gitlab с этим почему-то грустнее чем в github - squash merge выглядит корявенько на дереве). PR на 1000+ строк - требует обоснования почему такой большой.

Все что разраб делает в своих бранчах- как спальня, его личное дело

Да, мы так же делаем. В Gitlab мы делаем fast forward merge и squash commit. В такой конфигурации перед мержем в интерфейсе можно отредактировать merge commit message. Вот в него уже руками (к сожалению) тот кто мержит переносит описание из самого MR и руками вставляет ссылку на сам MR (без этого потом не найти связи между коммитом и MR). В таком виде у нас получается довольно удобная история в мастере.
Забавно что для того чтобы отредактировать commit message нужно чтобы было минимум 2 коммита)

Да, меня интересовали построчные изменения в режиме --patch. Буду знать, спасибо!

это кстати один из недостатков gitlab по сравнению с гитхабом который раздражает, в хабе очень все правильно - в текст коммита вставляется текст описания PR, а не как в гитлабе "Merge branch 'foobar' into 'master' ". ну и то что гитлаб squash делает на фича-бранче и все равно в итоге делает 2parents commit - это тоже странно

Unit of change = PR работает до тех пор, пока коду года два-три и в команде 4-5 человек. Ну и переезд репо с хостинга на хостинг всю историю PR и обсуждений убьёт.

я перешел полностью с cli+gitextensions на Sublime MErge с лицензией в начале карантина - в целом очень доволен, хотя workflow пришлось поменять немного

Это да, мы до этого использовали phabricator, там все было лучше))
В той конфигурации что я описал будет 1 коммит

Почему оно не может работать дольше 3 лет и в большой команде? Мы используем и вроде успешно, есть конечно при этом свои проблемы.
Про переезд да, мы до сих пор держим запущенный phabricator чтобы смотреть в нем историю обсуждений по старым фичам (больше 3-х лет назад).

Да, у этого метода есть ограничение на попадание в мастер. Если иметь дисциплину написания коммит-сообщений (подкреплённую server-side валидацией) - можно пушить в мастер напрямую.

У нас девятилетняя кодбаза и команда из 20 человек, в которой только один работает с самого начала и он на удалёнке. То есть постоянно возникают ситуации типа "тут вот что-то пять лет назад написано, а почему так написано - непонятно и спросить не у кого". И тут гранулярные коммиты помогают получить ответ на вопрос "почему", который другим способом не получишь.

это да, тут работает когда остаешься на хостинге (что большинство обычно и делают. но также ломаются и ссылки на всякие jira\redmine и все такое. хранить историю в сообщениях коммитов имхо также не удобно как и в сообщениях PRов, или комментариях багтрекеров. Что меня удивляет, что никто особо не пытается сделать распределенный багтрекер который бы поверх самого гита работал бы - т.е. типа .bugs и .tasks внутри репки - содержат именно это, а при выкачивании дают интерфейс редактирования. Ибо что пулл реквесты что треллы асаны и джиры - не очень хорошо ложатся на версионирование кода

Были ли тут обсуждения на тему : куда мигрировать с Тиньков?

На Рокет же