расскажу, хоть немного уже подзабыл — везде ж торопишься. Вот сейчас я посмотрел работающий сервис, он выглядит так:
CGroup: /system.slice/mcs-hermes.service
├─69315 /bin/bash /var/some_app/some_app.jar
└─69331 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Dspring.config.location=/opt/some_folder1/application.properties -jar /var/some_app/some_app.jar
Т.е. запущен jar и указан путь к файлу настроек, который лежит отдельно от jar.
И мы пробовали разные варианты запуска:
java -jar some_app.jar
bash /some_app.jar
В некоторых случаях подхватывался файл настроек (этот вот отдельный) в некоторых нет. Причем если просто из командной строки — то, например, да, если из сервиса, то, например, нет.
Короче говоря оставили в сервисе тот вариант, который «сработал» (в результате экспериментов). И так — ок.
Доброго дня! вы так это сказали, что как будто бы база окажется не большой и не очень важной, то это будет обидно для вас и как минимум обесценит весь наш труд ;)
Так или иначе, мы выделяем следующие классы систем:
Mission critical - Критически важные ИТ-системы/ платформы, нарушения в работе которых приводит к существенным невосполнимым потерям и серьезно затрагивает ключевые бизнес-процессы даже в краткосрочном периоде
Business critical - Критически важные ИТ-системы/ платформы для бизнеса, выход из строя которых приводит к серьезным потерям для бизнеса, однако в краткосрочном периоде ключевые бизнес-процессы могут осуществляться с незначительным снижением уровня сервиса
Business Operational - ИТ-системы, выход из строя которых затрагивает только внутренние процессы и не приводит к потерям в среднесрочном периоде, в долгосрочном периоде создаются существенные неудобства пользователям
Office Production - Некритичные ИТ-системы, простой которых в среднесрочном периоде не влияет на бизнес-процессы
В статье идет речь про Business Operational систему. И да, база не очень большая, около 300Gb (размер в ora и pg примерно одинаков), основной поток данных - интеграционный и в результате работы фоновых процессов (расчетов), т.е. точечных "небольших" вводов данных (пользовательских) не много, больше сосредоточено на сбор данных из внешних систем (можно сказать, что система аналитическая). Партиционирование есть на крупных таблицах, но его немного.
вы правы, я просто имел ввиду мысль чтобы понимать физику процесса. Мы то как столкнулись с этим — «там» работает (rhel), «тут» нет (redos). И сидим думаем, какое решение предпринять. Но объяснение выше в целом дает понимание полностью.
Вы мне напомнили старую байку, как какой то шутник в дебрях сишного проекта переопределил в дефайнах true = false и наоборот. У вас очень классный комментарий, я этого не знал. Но на мой взгляд, этим заниматься не стоит — мы же не эмулируем оракл со всей его внутрянкой (несмотря на orafce), а все таки пытаемся с него смигрировать — так или иначе, с допущениями, нужно принимать философию той БД, на которую мы переходим, тем более она более стройная (по крайней мере в этом месте).
Да нет, пока только запустились. Вроде все шевелится также (интерфейс), да, пока видимо что немного помедленнее, но решили заменить SAS диски на SSD, после чего еще раз посмотрим. Тонкий тюнинг будем делать когда все номинально запустится в полном объеме, а то попадаются разделы приложения, которые нужно «шлифовать» (исправлять запросы и т.д.).
Не помню почему у меня не получилось, это не на этом проекте было, хотя я возможно просто не догадался до вашего решения, надо бы попробовать, спасибо!
ну да, примерно так и переписали ;) Оракл по моему просто это условие с селект_максом выкидывал, но почему пропускал, не ругаясь? — камень в его огород.
Да, исполняемый. Спасибо за советы, дойдут руки — докопаюсь. Мне нравится разбираться в природе вещей. То, что JAR может быть полутекстовым для меня стало открытием и именно на этом проекте.
Да, исполняемый. Спасибо за советы, дойдут руки — докопаюсь. Мне нравится разбираться в природе вещей. То, что JAR может быть полутекстовым для меня стало открытием и именно на этом проекте.
Мне вот честно говоря это непонятно, баш запускается из любого каталога, это значит, что в path он прописан. Но при использовании в сервисе — помогло только написание полного пути. Вопрос почему? Я не знаю. Но решение найдено и оно вполне работает, поэтому — ну, пусть так и будет.
Это техническая статья, я об этом сразу написал в самом начале: «а в этой речь пойдёт о программной стороне вопроса». Все сказанное актуально и для обычного «ванильного» постгреса, но нам желательно использовать ПО, которое «входит в единый реестр российских программ и баз данных», поэтому мы работаем на нем.
Ну и вообще, стоимость лицензий на PGPro — вполне себе скромна. Если посмотрите, мы специально выбрали Standard версию, которая раза в 4 дешевле Enterprise. Потому что ее в данном случае хватает.
О, на это отвечу.
Джарники, когда они запускаются как сервисы и когда они запускаются «отдельно», как то по разному интерпретируют пути запуска. Т.е. у нас конфиги лежат в отдельных папках, сами джары — в отдельных. И мы по разному перепробовали и оно по разному подхватывает, т.е. ваш пресловутый (и самый популярный) «джава минус джар» пробовали сразу.
Теперь о том как работает магия (я сам долго не мог понять «а почему оно вообще работает»). Я разбирал этот вопрос. Сам Jar файл, как выяснилось, может быть «полутекстовым, полубинарным». Т.е. сначала в нем идет текст:
#!/bin/bash
и куча команд как это все запускается.
А потом мы уже видим начало бинарной части, с характерным идентификатором:
exit 0
PK #”йR META-INF/юК PK PK
Но вот я посмотрел другие jar файлы, из других проектов — они просто состоят из бинарной части, т.е. чистого архива. Видимо есть какой то хитрый механизм сборки (скорее всего какой нибудь плагин мавена), который «текстовую часть» (для баша) «дорисовывает».
Вот как то так.
Ну тут опосредованно. На самом деле это намного более хорошо, что она строгая в пг, но в данном конкретном случае — она привнесла больше всего проблем. С третьей стороны — SQL язык с историей, как мне кажется он проектировался «с нестрогой типизацией», а там дальше уже как у кого пошло ;)
CGroup: /system.slice/mcs-hermes.service
├─69315 /bin/bash /var/some_app/some_app.jar
└─69331 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Dspring.config.location=/opt/some_folder1/application.properties -jar /var/some_app/some_app.jar
Т.е. запущен jar и указан путь к файлу настроек, который лежит отдельно от jar.
И мы пробовали разные варианты запуска:
java -jar some_app.jar
bash /some_app.jar
В некоторых случаях подхватывался файл настроек (этот вот отдельный) в некоторых нет. Причем если просто из командной строки — то, например, да, если из сервиса, то, например, нет.
Короче говоря оставили в сервисе тот вариант, который «сработал» (в результате экспериментов). И так — ок.
Доброго дня! вы так это сказали, что как будто бы база окажется не большой и не очень важной, то это будет обидно для вас и как минимум обесценит весь наш труд ;)
Так или иначе, мы выделяем следующие классы систем:
Mission critical - Критически важные ИТ-системы/ платформы, нарушения в работе которых приводит к существенным невосполнимым потерям и серьезно затрагивает ключевые бизнес-процессы даже в краткосрочном периоде
Business critical - Критически важные ИТ-системы/ платформы для бизнеса, выход из строя которых приводит к серьезным потерям для бизнеса, однако в краткосрочном периоде ключевые бизнес-процессы могут осуществляться с незначительным снижением уровня сервиса
Business Operational - ИТ-системы, выход из строя которых затрагивает только внутренние процессы и не приводит к потерям в среднесрочном периоде, в долгосрочном периоде создаются существенные неудобства пользователям
Office Production - Некритичные ИТ-системы, простой которых в среднесрочном периоде не влияет на бизнес-процессы
В статье идет речь про Business Operational систему. И да, база не очень большая, около 300Gb (размер в ora и pg примерно одинаков), основной поток данных - интеграционный и в результате работы фоновых процессов (расчетов), т.е. точечных "небольших" вводов данных (пользовательских) не много, больше сосредоточено на сбор данных из внешних систем (можно сказать, что система аналитическая). Партиционирование есть на крупных таблицах, но его немного.
Ответил я на ваши вопросы? ;)
Тут например описано: habr.com/ru/company/tensor/blog/507056
SELECT
count(*) FILTER(WHERE prime < 10) countlt
, count(*) FILTER(WHERE prime > 10) countgt
FROM…
Только не говорите, что можно sum(case( использовать, это я знаю ;) тут все же изящнее и по моему возможностей больше
echo $SHELL
/bin/bash
Мне вот честно говоря это непонятно, баш запускается из любого каталога, это значит, что в path он прописан. Но при использовании в сервисе — помогло только написание полного пути. Вопрос почему? Я не знаю. Но решение найдено и оно вполне работает, поэтому — ну, пусть так и будет.
Ну и вообще, стоимость лицензий на PGPro — вполне себе скромна. Если посмотрите, мы специально выбрали Standard версию, которая раза в 4 дешевле Enterprise. Потому что ее в данном случае хватает.
Джарники, когда они запускаются как сервисы и когда они запускаются «отдельно», как то по разному интерпретируют пути запуска. Т.е. у нас конфиги лежат в отдельных папках, сами джары — в отдельных. И мы по разному перепробовали и оно по разному подхватывает, т.е. ваш пресловутый (и самый популярный) «джава минус джар» пробовали сразу.
Теперь о том как работает магия (я сам долго не мог понять «а почему оно вообще работает»). Я разбирал этот вопрос. Сам Jar файл, как выяснилось, может быть «полутекстовым, полубинарным». Т.е. сначала в нем идет текст:
#!/bin/bash
и куча команд как это все запускается.
А потом мы уже видим начало бинарной части, с характерным идентификатором:
exit 0
PK #”йR META-INF/юК PK PK
Но вот я посмотрел другие jar файлы, из других проектов — они просто состоят из бинарной части, т.е. чистого архива. Видимо есть какой то хитрый механизм сборки (скорее всего какой нибудь плагин мавена), который «текстовую часть» (для баша) «дорисовывает».
Вот как то так.