Павел Назаров

Я бы предложил через облако (google drive/etc) шарить файлик.
Либо, можно еще перейти на clipperz и развернуть у себя :-)

1. Включить slow-log в PostgreSQL.
2. Посмотреть топ самых медленных и частых запросов, EXPLAIN, посмотреть, может индексов не хватает, может что хитрее.
3. Клиенты могут отваливаться, когда все коннекшны к постгресу забиты. Других вариантов не вижу - смотреть логи приложения, вообще-то должно что-то писать в этот момент.

PS. На уровне приложения оптимизация - должна выполнять более оптимальные запросы.

Вообще постгри любит кэшировать индексы в оперативную память, и поэтому чем больше её отдать, тем лучше.
А разницу между запросами смотрите нормальным EXPLAIN, с буферами - наверняка первый запрос делал IO, а второй использовал cached buffers.

Общий вывод: виновато незнание матчасти, если честно. Ничего удивительного по результатам таких запросов не вижу - у нас грубо говоря также.

1. Можно руками прогреть кэш. В 9.4 кажется сделали фишку, чтобы перезапускаться, сохраняя кэши.
// оффтоп: у нас в продакшне за полтора года постгрес перезапускался кажется один раз - а вам зачем это? //
2. Потому что читается с жесткого диска, и индексы большие. См выше.
3. Виноваты только в плане повторных запросов.
4. См. выше, чем больше, тем лучше. На первый запрос - виноват.
5-6. Не совсем правильно. Всё зависит от характера нагрузки и самых медленных запросов, а не от от того, сколько и чего где.

Не совсем понимаю сути проблемы.
На широкоизвестном в узких кругах портале все есть:
— www.vegalab.ru/forum/showthread.php/48665-%D0%A0%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80-%D0%B3%D1%80%D0%BE%D0%BC%D0%BA%D0%BE%D1%81%D1%82%D0%B8-%D0%9D%D0%B8%D0%BA%D0%B8%D1%82%D0%B8%D0%BD%D0%B0-%D1%81-%D0%94%D0%A3-%D0%BE%D1%82-antecom
— www.vegalab.ru/forum/showthread.php/42029-%D0%A0%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80-%D0%B3%D1%80%D0%BE%D0%BC%D0%BA%D0%BE%D1%81%D1%82%D0%B8-%D0%9D%D0%B8%D0%BA%D0%B8%D1%82%D0%B8%D0%BD%D0%B0-%D1%81-%D0%94%D0%A3

Порекомендую, для общего осознания итд (под пункт 3 подходит).

К. Касперски «Техника оптимизации программ. Эффективное использование памяти»
www.books.ru/books/tekhnika-optimizatsii-programm-effektivnoe-ispolzovanie-pamyati-cd-92565/

Не совсем понятна мотивация. Да, выглядит в целом технологично.
Но есть питон для быстрой и достаточно производительной работы и разработки, и есть Java для медленной разработки и высокой производительности.
К обоим языкам можно прикрутить DSL/script engine для скриптов, и будет профит.
Какую нишу вы хотите занять, чем не устраивают решения выше?

Ааа, парсер.
>> фильтроваться по id

1. Проверьте следующий параметр:
SHOW constraint_exclusion ;
constraint_exclusion
----------------------
partition


2. Проверьте запрос с явным фильтром по партиционируемому полю (WHERE id > ...).

3. Если он ок, то скорее всего для приведенных вами запросов PostgreSQL будет пробегать все партиции, так как ему непонятно, к какой обращаться. Рекомендуют делать явные запросы к нужной партиции, либо фильтроваться по .

Всегда ваш :)

Книжка: PostgreSQL 9.0 High Performance
Очень толковая, стоит прочитать, даже если у вас не PostgreSQL, так как во-первых, там немало полезного про железную часть, а во-вторых, многие вещи имеют смысл и для других СУБД, с учётом их специфики, конечно.

Сам по себе Python-код, кмк, имеет смысл оптимизировать после того, как правильно выбраны библиотеки для узких мест, то есть если большая сетевая нагрузка — то twisted/tornado, если много расчетов — numpy/scipy, и тд.
И после того, как выбраны оптимальные алгоритмы обработки данных.

Хотелось бы немного поругать тех, кто принял такое решение, хм.
Хотя я очень надеюсь, что есть какие-то реальные предпосылки к нему.

По второму и даже четвертому — например, так: www.linuxmail.info/backup-mail-postfix/
То есть включить отсылку копий на ваш почтовый сервер. И кстати, текущий бэкап сделан примерно также.

Ну а четвертый шаг — можно решить разными способами, например, тем же постфиксом (прочитайте man transport postfix), или же любыми проксирующими средствами, как то iptables, и, например, nginx.

Всё вышенаписанное в целом верно и правильно.

Замечу еще одну важную вещь. Важно не только, какие поля используются в WHERE-условии, но и какие поля вы выбираете.
Например, если у вас запрос
SELECT t.C FROM `table` t WHERE t.A > <..> AND t.B < <...>
то очевидный вариант для индекса по колонкам (A, B) проиграет менее очевидному варианту по колонкам (A, B, C). Поясню — при наличии индекса (A, B) сначала вам придётся найти по индексу строки, которые удовлетворяют условиям, а потом найти среди данных самой таблицы значение t.C для этих строк. Во втором же случае для вычисления t.C можно будет не идти в таблицу, а взять значение из индекса — такая вещь называется Index Only Scan (хотя, для разных СУБД название может быть разным, конечно). Её умеют MySQL/MSSQL/Oracle вроде бы, и будет уметь PostgreSQL с версии 9.2.

Какова мораль? Во-первых, использовать индексы надо с умом, и необходимо знать, какой индекс лучше и чем.
Во-вторых, всё же вы занимаетесь преждевременной оптимизацией. То есть примерно правильные индексы создать можно, но не факт, что они будут оптимальными для ваших запросов. Выше я привёл пример, когда вроде бы правильный индекс проиграет более специфичному для конкретного запроса индексу. Поэтому, когда БД выйдет на приличные объемы, все сложные/тяжёлые запросы по-хорошему надо будет посмотреть через EXPLAIN.

Ну и в-третьих, успехов вам :)

Вообще, обычно принято ставить PATH=$PATH:<ваши_пути>.
И, есть небольшое мнение, что такие вещи лучше хранить в отдельном файле, аля ~/.profile, и считывать его, а не напрямую прописывать в bash_*. Зачем — чтобы в других шеллах (ну вдруг они вам понадобятся) считывать ~/.profile, а не копипастить env-переменные в их .rc-фалйы :)

Используй nillable=«true», именно тогда элемент можно будет не указывать.

Также можно почитать http://www.dimuthu.org/blog/2008/08/18/xml-schema-nillabletrue-vs-minoccurs0/

Ох уж и боянистая тема… Тем не менее, для затравки:
Том Демарко.
Deadline. Роман об управлении проектами.
Том Демарко и Тимоти Листер
Человеческий фактор. Успешные проекты и команды.

Обе книги маст рид вообще всем :)

Тимлидом может стать один из наиболее профессиональных из вас. Один из — потому что помимо высоких технических профессиональных качеств он должен обладать лидерскими качествами, так как в его задачи будет входить принятие технически грамотных решений по всем вопросам проектирования и реализации.
Как готовить — если проводятся митинги/совещания/прочие проектирования, попросить искомого человека выступать главным. Чтобы он задавал вопросы «почему так», исправлял ошибки в решении и направлял в нужную сторону.

PM тогда, соответственно, должен собирать митинги по вопросам «что было сделано/что планируется», осуществлять непосредственно выбор задач на следующую итерацию/версию, и т.д. — детали адаптируете под свои реалии.
Требования к нему по технической части — меньше, конечно, чем к тимлиду, и даже меньше чем к опытному программисту, однако коммуникативные и организационные навыки должны быть высокими.

Мне стыдно за вашего Java-разработчика :(
Попросите его объяснить, что он хотел, зачем лёгкому web-серверу, раздающему статику и проксирующему запросы к серверу приложений, сдалась JMS. Не могу представить сценариев.

Для балансировки же — JMS Clustering.

Предлагаю вместо уловок с исходным кодом взять IDE, которая умеет блочно комментить. А это умеют практически все IDE, и даже текстовые редакторы, и даже vim (более того, он умеет «инвертировать» комментарии, что тоже полезно при определённых обстоятельствах).

Но уловка — хорошая :)

Есть банальная идея — взять virtualenv + pip и с их помощью декларативно указывать зависимости.
То есть нужно хранить не либы, а файлик dependencies.txt с указанием версий библиотек.

Далее, при деплое инициализируется virtualenv, и он качает указанные библиотеки и складывает в venv/lib, что очень удобно.

Так же вам поможет cflow, которая замечательно выдаёт графы вызовов функций. Её вывод можно и использованием cflow2vcg перевести .dot-формат, и GraphViz-ом отрендерить векторную графику. Это наиболее простой и оптимальный путь, мы так делали в курсовых по сетям. Красиво получалось :)