Pull to refresh

Comments 85

Плюс в карму хотя бы за упорство.

В этой постгре черт ногу сломает, про единички просто убило)

В тегах лучше поставить pgsql/postgresql, чтобы кто-нибудь наткнулся в будущем на статью и не тратил 3 часа на сборку и установку бекенда.
Добавил в тэги.
Спасибо :-)
Году в 2005-2006 я сильно любил gentoo, но потом моё время стало дорогим и я познал счастье deb.
Хорошая статья :)
А вот я совсем наоборот, после того как «приобщился» к gentoo забыл про все остальное в качестве серверных ОС, поскольку на Deb или чем-то другом rpm'ном практически не возможно завести какую-нибудь хитрую комбинацию софта… Приходилось половину системы выкашивать… После того как познал gentoo, забыл про эти проблемы…
А что мешает пакет то собрать нужный из сырцов?
Ручками если собирать да ставить — нет инструмента удаления пакетов, отслеживания коллизий. Да много чего :-)
Не зря же менеджеры пакетов придумали.
Не понял, если вы пакет собрали, зависимости то понятны же какие. Я именно про сборку пакетов, а не gentoo way в дебиане как некоторые любят.
Видимо да, кстати неплохо бы layman сделать. Что бы другие не мучились :)
На бубунте завёл зеркало OSM сервера.
Собирал из сорцов все его компоненты кроме pgsql ничего не выкосил пол системы ;)
это о чем-то говорит? кроме как о том что вы собрали из сорцов OSM сервер? это доказывает что на бубунте также легко собирать нужное ПО с нужными версиями либов как на gentoo?
Нет просто для ОСМ сервера надо было собрать очень много всего, в том числе и системного, а не просто ОСМ сервер
PS
ЗЫ www.openstreetmap.org
Я так понимаю, что за все эксперименты заплатил Ваш работодатель?

Немного поясню свою мысль.

Производитель ПО выложил протестированные и готовые к использованию пакеты для определенной ОС, производитель дает гарантии работоспособности и поддержки в случае если используется только данная ОС.

Вы Вместо того чтобы выбрать инструмент исходя из потребностей выбираете совершенно другой инструмент исходя из собственных предпочтений, мучаетесь неделю или две стараясь заставить его работать.

Внимание вопрос в курсе ли работодатель что вы просто «украли» у него две недели Вашего рабочего времени?

В курсе ли работодатель, что Вы сделали костыль гарантии работоспособности которого не даст никто?

Все больше утверждаюсь в мысли, что существует класс людей обладающих определенными знаниями, но которых надо принудительно изолировать и не давать возможности пользоваться данными знаниями — так как они дискредитируют и портят имидж своей профессии.
Упорство — это когда вводишь пароль до тех пор, пока система не соглашается. Автору просто за упорство плюс )))
Не спорю, автор стал обладателем уникальных знаний, но проблема в том, что он нигде не сможет ими воспользоваться — такими вещами НИКТО в продакшн заниматься не станет, ибо любой сбой может обернуться не кислыми проблемами за которые понесет ответственность наш дорогой litnimax.

Или если переходить на аналогии, то его уникальные знания, это как член длинною в метр — очень круто, но абсолютно бесполезно.
Если в будущем возникнет проблема и не будет инструкции по ее решению, то автор решит проблему, а некоторые встанут в ступор.
> автор стал обладателем уникальных знаний, но проблема в том, что он нигде не сможет ими воспользоваться

Скачав пакет от Етерсофт, заметил патчик к патчам от 1С. Видимо, ребята из Етера не только воспользовались полученными ранее знаниями, но еще и проблемы порешали.
Мы также пока ставили все патчи, внимательно изучали, что они делают.
Теперь, если база будет себя неадекватно себя вести, будет хорошее представление, куда рыть.

А вот если бы я это не написал, точно бы знания зря пропали. Во всех статьях просто детский сад.
Если у Вас нет MVARCHAR, значит нет библиотеки ICU. Установите библиотеку, и переинициализируйте базу данных.

Вот ответ «профессионалов» консультантов. Шаг влево-вправо — они руки разводят. Ибо просто не понимают основополагающих механизмов.
То что вы пишите, это всё хорошо и правильно, НО в теории!
Видимо с 1С вы общаетесь мало, иначе не стали бы поминать гарантии работоспособности от 1С!
Уж, поверьте если бы всё было так просто, кому бы сдались услуги интеграторов по настройке серверов, все бы просто ставили 1С пакетик и радовались жизни, до поры до времени…

Про саму 1С бухгалтерию я вообще молчу, именно «гарантии работоспособности от 1С» породили полчища «1С-Програмист-ов» как профессию.
Ибо даже в пределах банальных стандартных конфигураций, админ не справится, особенно если разрешит авто-обновления, которые могу оказаться губительно сырыми для БД или не вполне работоспособными для бухов.
(Мои бухи уже знают что такое xml и как его править руками, что бы такском съел выгрузки из 1С)
А ещё у 1С есть такая конфигурация как «Зарплата и управление персоналом» — ЗУП в простонародье, которая сделана через ЖОПУ (я не побоюсь этого слова), так что порою разобраться в ней нереально даже человеку много лет проработавшему интегратором 1С решений. Тут нужно банальное знание того как именно она сделана, и никак иначе.
В общем петь дифирамбы 1С можно ещё долго, и я это всё к чему…

… К тому что чувак не зря потратил время, если он научился настраивать работоспособный сервер для 1С, то это дорого стоит в прямом смысле слова дорого, и работодателю тоже не стоит расстраиваться тк, это не просто экономия, это безопасность бизнес процессов, ведь базы имеют обыкновение падать именно тогда, «когда надо было ещё вчера»…
Конечно сервачёк, надо по тестировать под нагрузочкой, припаять туда авто бэкап базы (ой как порою помогает, особенно когда «надо было вчера»...), взять какую нить олдовую базу, последовательно по накатывать обновления, и если это действительно работает стабильно то, работодателю не о чем будет париться, а у сотрудника может появиться не плохой источник дополнительного дохода :-)
> Конечно сервачёк, надо по тестировать под нагрузочкой
Парни, мы раньше сидели на SaaS'овских приложениях по учету торговлей и складом, вконец упарившись, решили уйти на 1C. Так что эпопея только началась :-)

Я бы с радостью поставил OpenERP например, но только адаптировать ее полностью свосем жестко будет. Да, забыл сказать, у нас в компании винды до сих пор не было! Из-за 1С пришлось себе на горло наступить :-P
>> К тому что чувак не зря потратил время, если он научился настраивать работоспособный сервер для 1С, то это дорого стоит в прямом смысле слова дорого, и работодателю тоже не стоит расстраиваться тк, это не просто экономия, это безопасность бизнес процессов, ведь базы имеют обыкновение падать именно тогда, «когда надо было ещё вчера»…

Знаете, я немало поднял связок Win Srv + MS SQL + 1c v7.7 / 1c v8.x. Даже при физическом умирании сервера максимум что требовалось — достать mdf, сама по себе база никогда не рушилась, я молчу про бакапы. Так что «понимание как работает сервер для 1С» здесь следует читать как «понимание как сделать PostgreSQL сервер для 1С Предприятия если „по каким-то причинам“ не можется /не хочется/ использовать поддерживаемые решения», т.е. случай крайне редкий, и нужный только ограниченному кол-ву людей.

О «безопасности бизнесс процессов» в свете использользования патченного руками и кое-как собранного софта я промолчу.
Мне интересно, почему софт, пропатченный руками разработчика — это надежно, а тот же софт, пропатченный руками другого не менее, а скорее более компетентного в системных вопросах — не надежно :-)
Не стоит забывать, что помимо накладывания патчей на исходные тексты перед работой следует еще и этап компиляции.
Я к тому, что этот разработчик не только код правит, но и компилирует известным ему правильным методом.
Ну вообще-то инструкции по сборке тоже входят в пач, а именно в Make-файлы. Разве что речь идет о дистрибьюции в бинарном виде. Но и там Linux дает мощные инструменты реверс-инжиниринга.
Я исхожу из принципа что, если пропатчил разработчик, то даже если криво — это известно многим (ибо тупо вылезает у многих), если пропатчил внутренний работник — то есть отличный от нуля шанс что будет что-то уникальное, соответственно «если чё» может потребоваться дохрена времени и ресурсов для восстановления для поиска в чём дело, а это более опасно для БП чем «известные» проблемы от разработчика.
Это не отменяет поправки на квалификацию человека патчевшего сервис.

ЗЫЖ я в аутсорсинге работаю, у нас иногда радикально подход отличается от in house ;)
Все вы верно говорите. Кроме одного. Кто понесет ответственность при некислом сбое на типовой конфигурации, производитель? В лицензии обычно пишется отказ от любой ответсвтенности. Так вот при некислом сбое шанс оживить систему будет гораздо выше именно у этого админа.
Подождите-подождите, вы о каких таких протестированных версиях, поддерживаемых разработчиком, говорите? О постгрессе для центоси от 1С?? Да это глюкавое убожество, сделанное на коленке школьниками, конечно установка всего этого добра под генту ничего не исправит, но всё же называть постгресс от 1С протестированным продуктом…
я об этом v8.1c.ru/overview/postgresql_patches/8-4-1/postgresql-8.4.1-1.1C.src.rpm
Рекомендованная 1c версия PostgreSQL под Linux. Кривая или нет, это совсем не тот вопрос. Вопрос в том поддерживаемая или нет.

Насчет сапорта ради интереса попробуйте обратиться в сапорт 1c с вопросом «я тут пересобрал PostgreSQL из сорцов с вашими патчами под МОЙ_ЛЮБИМЫЙ_ДИСТРИБУТИВ и у меня не работает» и будете крайне удивлены.
Из вашей последней фразы можно выкинуть вопрос и суть останется такой же: обращаться в саппорт 1С бесполезно практически по всем вопросам, по техническим — уж точно. Тем более не совсем понятно как можно добиться такой ситуации, что постгресс, который преспокойно собирается на всех платформах, вдруг после извращений со стороны 1С собираться перестаёт.
В году эдак 2003 я работал сисадмином в операторе IP телефонии, по совместительству админом Sybase, а также админом биллинга.
Мы заплатили 3 штуки гринов за поддержку оперативную (типа оператор телефонии, важна скорость). Так вот, когда в один чудесный день база залочилась, поддержка нервно курила до 19 часов, а потом спать пошла. А мне пришлось до утра курить sybase, и в итоге откатить базу на момент аварии (благо недавно только открылись, клиентов мало было). А поддержка так и не разобралась. А еще дня через три мы смогли не только восстановить (спорта ради) поврежденную копию, да еще и оттюнили базу так, что летала как ракета. Так что на суппорт я разучился полагаться уже давно.
Можно найти интервью, почему штатный PGSQL их не устраивал, полезно для самообразования.
Вкратце и утрированно — PGSQL знать не знает про какую-то там кириллицу.
LOL :-)
база в кодировке ru_RU.UTF-8 :-)
Я ж говорю «утрированно».
Дело в сортировках, искать оригинальное интервью лень, вот тут postgresql.ru.net/node/29777 чуть-чуть есть информации.
именно по означенной причине, для интеграции с 1C в PostgreSQL добавлен патч, предоставляющий специальный тип mchar, который как раз и не чувствителен к регистру при операциях сравнения
у вас в профиле ЦентОС написано
и да, возможно это от вас надо изолировать профессию, а то знаете ли сисадмин гордящийся своими сертификатами и умением делать всё по инструкции сертифицированными методами это нихрена не сисадмин
Я себя стал ловить на мысли, что я последнее время делаю по инструкциям. Это с одной стороный хорошо, но с другой стороны, натаскают на курсах тебя кнопочки тыкать, дадут сертификат, а дальше… дальше всё грустно.
> Я так понимаю, что за все эксперименты заплатил Ваш работодатель?
Эээ… вообще-то я совладелец собственной компании, и к сожалению, свои 10 лет опыта линукса передать сотрудникам как-то сходу не получается :-) Поэтому периодически закатываю рукава и показываю «кто тут папа» :-)
Сел за комп вчера в 12 утра. Встал сегодня в 6. Итого, 18 часов ушло на то, чтобы полностью разобраться в вопросе того, что же из себя представляет пострес от 1С. Теперь мы можем ее поднять из исходников на любом сервере.

> Внимание вопрос в курсе ли работодатель что вы просто «украли» у него две недели Вашего рабочего времени?
18 часов, а не две недели. При этом я еще отвлекался на чтение почты, просмотр и отписку в тикеты по разработке других продуктов, общение на форуме :-P

> В курсе ли работодатель, что Вы сделали костыль гарантии работоспособности которого не даст никто?
Уважаемый. Воздержитесь от таких выводов :-) Мы постигали суть вещей, а не костыли делали!
Нормальные разработчики адаптируют свои продукты к мэйнстриму, а не наоборот!

Все больше утверждаюсь в мысли, что существует класс людей обладающих определенными знаниями, но которых надо принудительно изолировать и не давать возможности пользоваться данными знаниями — так как они дискредитируют и портят имидж своей профессии.

А еще есть хакеры в настоящем первозданном смысле этого слова, для которых не бывает нерешаемых задач :-)

> так как они дискредитируют и портят имидж своей профессии.
Политика 1С такая — знания дают только своим франчази, которые рубят денег с интеграции. И только и слышишь истории, как ходят месяцами «бизнес-анализ» делают, потом что-то «пишут», а потом проект стоимостью в 3 ляма рублей проваливается, так и не заработав. Так что не надо о «профессионалах», знаем таких немало. В общем, не хочу ввязываться в спор. Я понял типаж, который Вы имели в виду. Извините, не наш случай.
Прошу пардона, не имел цели Вас оскорбить.

>Я понял типаж, который Вы имели в виду. Извините, не наш случай.

Радует.
странно. я нашёл патчи, скачал деб-срц постгресса, кинул патчи в нужный каталог, запустил пересборку — собралось. пакеты поставились, работают. на всё ушло часа два-три от момента, когда я узнал, что существует 1С под линукс.
Вообще по тестам на РЕАЛЬНОЙ базе довольно крупного промышленного предприятия PostgreSQL с 1С работал примерно в 3-5 раз медленнее чем MS-SQL, конечно постгрес это БЕСПЛАТНО… но оно надо?
Надо. Ибо на реальной базе не 1С посгресс работает быстрей, а дальше всё упирается в полную криворукость программистов 1С. Плюс ради 1С вводить в инфраструктуру серверы MS зачастую глупо, MS-SQL вообще странный продукт. Тогда уж ораклю надо, а не MS-SQL… Ну и в любом случае криворукость недопрограммеров из 1С ещё очень не скоро позволит этому комплексу нормально работать в принципе, не то, что нормально работать с постгрессом…
Я говорю про абсолютно реальный тест, одна и та же база, не надо тему разговора переводить на 1С… С 1С все понятно и с их программерами тоже, я сильно глубоко знаю как эта штука работает поэтому прекрасно понимаю что работать нормально ОНА НЕ МОЖЕТ ПО ОПРЕДЕЛЕНИЮ, по карйней мере с планом счетов, структура хранени и самое главное блокировок не позволит :)

Но а тестирование проводили для понимания стоит-ли платить за MS, выяснилось что стоит, база на постгресе крутилась «в тупую» в 3 раза медленнее… это факт жизни…
Я когда перешел в другую компанию работать, году эдак в 2004, там тот же биллинг, что мы sybase гоняли, работал под MSSQL. Потратил целый день на гуглинг по вопросам «MSSQL tuning». Потом не выдержал и позвонил товарищу мелкомягкому… Тот долго не мог понять, о каких именных кэшах для таблиц, индексов, и процедур я пытаюсь говорить. В потом в шоке был я — MSSQL не имеет механизма тонкой настройки.
Это я к тому, что postgres в отличие от MSSQL обладает механизмами тюнинга. Видимо, в Вашем тесте ими не воспользовались :-)
Ибо какой бы кривой 1C ни была, SQL он и в африке SQL. И если один и тот же запрос работает в три раза быстрее на MSSQL, значит что-то не так…
В корне не верное утверждение, ибо трэйс 1С'а характерен ОЧЕНЬ сложными запросами, и вот тут в дело вступает оптимизация выполнения запроса и раскидка по потокам, правильная работа со статистикой… И быстродействие может отличаться, не то чтобы в разы, а на ПОРЯДКИ… SQL это совсем не линейный язык программирования :)
Гугл на запрос google.com/search?q=mssql+tuning выдает 198 тысяч результатов. История про мелкомягкого товарища вообще притянута за уши. Либо приводите факты либо не пишите таких сообщений.
Я искал возможность точного управления выделением ресурсов под объекты баз данных. Не нашел. Их нет. Сравните, что выводит sybase tuning и mssql tuning.
При чем тут НЕ 1С?
Вы вообще не в тему со своим ответом.
На реальной базе в некоторых местах производительность на постгресе была в 100 раз хуже чем MSSQL.
И, соответственно, когда на реальном предприятии возникает вопрос покупать ли MSSQL, то однозначный ответ — да, покупать.
Потому что можно месяцами тюнинговать постгрес, а можно купить MSSQL и спокойно работать.
В прошлом году инженеры Sun показали всему миру, что PostgreSQL не уступает в производительности Oracle.
postgresmen.ru/news/view/44

MSSQL нервно курит :-) Похоливарим? :-P
MS-SQL не поддерживает большие запросы. Мы из-за этого и перешли на постгре.
боюсь даже спрашить что для вас значит «большой запрос»…
По тестам? Дайте мне SQL трейсы этих тестов, и я скажу Вам, в чем причина.
Когда-то опять же в былое операторское время программист биллинга хвалился процедурами на 5 страниц А4. Которые при первом запуске ложили базу. А потом бегал и ныл типа оптимизируй… После оптимизации процедура отарабатывала за секунды.
Вот такие обычно программисты :-)
Да причем тут это, вы писали большие учетные системы на 1С? Или теоретизируете исходя из опыта SQL-программирования, это разные вещи… Запрос реальный формирует не программист, и блокировками некоторыми (например на таблицу с аналитикой) рулить не возможно, поэтому как ни пиши НИХРЕНА не выйдет… надо или полностью переписывать логику учетной системы, или менять некоторые места в самой платформе…
Ради интереса понаблюдаю, насколько 1С работает с уровнями изоляции транзакций :-)
Вообще я бы не хотел развивать тему плохой или хорошей 1С. Большой продукт. Хорошо, что на куски не развалился :-)
И в конце-концов, победителей не судят — ведь работает же несмотря ни на что?
Значит, не все так плохо.
Но уверен, с системной точки зрения есть запас для оптимизации.
Будем выживать. Я же написал, эпопея только начинается :-)
Гыгыг… насчет работает это да! :) но поковыряйтесь просто в структуре запросов и хранения, там далеко ходить не надо :) ключевое слово «таблички с буковками ED» и блокировки на них ;)
Не совсем понятно что вам не нравится. PostgreSQL или все же то как сделан 1C для PostgreSQL.
PostgreSQL отличная БД, понятно что opensource и в чем то может уступать MS-SQL, а в чем то и выигрывать (версионность).
Уверен что проблема в том, что 1С плохо оптимизирован по PostgreSQL.
По логике разработчиков из 1С это PostgreSQL плохо оптимизирован под их систему :)
На форуме gentoo.ru за такую сборку вас бы четвертовали ;). Надо было идти до конца и таки написать ebuild да и запихнуть его в локальный оверлей )
Гы. Соглсен. Не gentoo way. Но еще не вечер :-)
Пути поправим, ебилд сделаем. Просто у нас задача была развернуть изолированный постгрес, у нас же родной работает в нормальных путях. Вот и запхали в /usr/local/pgsql, тем более он сам туда полез :-)
Ну кстати мб и пригодится кому еще, так что не смею вас останавливать )
В свое время так и сделал. К счастью теперь не занимаюсь этими вопросами.
А не знаете чем 1C не угодил стоковый постгресс?
Свои типы, операторы сравнения, сортировки — чтобы по минимому поддерживать разные диалекты SQL. IMHO.
Лучше бы слои совместимости написали между базой и программой. А то выглядит как один огромный костыль.
Не хватало какого-то функционала. Пропатчить постгрес было проще, чем адаптировать 1C.
www.inp.nsk.su/~baldin/PostgreSQL/1C/1C.html
Это, правда, старое интервью, возможно с того момента действительно договорились с постгресовцами и часть уже штатно в нём есть.
Не знаю, придётся ли в ближайшее время переходить на постгри, но комменты почитал с удовольствием…
У нас на серваке стоит PostgreSQL 8.4.5 с PostGIS на 5432 порту, под 1С установили 8.3.8 по данному руководству (5434-й порт). Возник вопрос (цитирую коллегу): «как правильно перенаправить 1С на этот порт». Может поможете советом? Заранее спасибо.
Да, 1С не понимает стандарт host:port.
Два варианта.
Системную посадить на 127.0.0.1:5432, а 1С-овскую — на 192.168.1.1:5432.
Параметр listen_addresses в postgresql.conf.

Если же к системной тоже по сети бегают, то надо также разделить по адресам, но уже оба сажать на eth0 — Поднять алиас ifconfig eth0:0 192.168.100.2 например.
UFO just landed and posted this here
Не на чем было их выполнять. Да и не особо хотелось. Хотели ручками, до самой глубины :-)
зачем использовать генту, если там всё нужно собирать вручную?
убунту лучше!
на gentoo обычно никто руками не собирает, если только не желает потрахаться нестандартно…

то же накладывание патчей и изменение параметров конфигурации делается изменением одного ebuild-файла за пять минут…

да и чтобы поставить в другое место тоже немного усилий потребуется…

зато был бы готовый ebuild, из которого можно бы было сделать patch и для последующих версий и автоматом накатывать…
мм, если рассматривать это как искусство — преклоняюсь.
если думать о том как вы будете обновляться (если 1с вдруг выпустит обновления) — очевидно что придется еще раз совершить весь танец с бубном

помнится, был один ниндзя, запускавший оракл на фряхе… наверное стоит уже сделать блог «Перпендикулярно требованиям»
А нафига было собирать icu ручками с префиксом /usr/local/icu, если можно было сразу взять пакет icu-${VER}_dev или ic-${VER}-devel? Это тоже «чтобы никто не догадался»?

По поводу ненакладываемых патчей: могли и src-пакеты кривой выложить. Если посмотреть, там и такое встречается:
%patch1 -p1
%patch3 -p1
# patch5 is applied later
%patch6 -p1
%patch6 -p1 # почему дважды???
%patch8 -p1
%patch9 -p0
%patch10 -p1
%patch11 -p0
ICU в системе не нужна. От нее нужна только пару либ. Поэтому их берем, остальное сносим.
Но в принципе да, можно.
Только что взяли постгрес от Етерсофта (в деб пакетах). Установили на дебиан.
Так вот, все модули есть (mchar, и 2 других), но в базу содержимое скриптов, добавляющих эти типы, не попало. Вот так вот.
Sign up to leave a comment.

Articles