Сравнение скорости работы 1С:Предприятие на MsSQL и PostrgeSQL

ОЗУ Windows 2003 Server

Дальше не читал.

ОЗУ Windows

Это как поясните мне неучу?

криогенная камера вышла из строя?

ОС Lunix

Прекрасно.

Как не странно, такая ОС есть (вернее была)
http://uk.wikipedia.org/wiki/LUnix
http://en.wikipedia.org/wiki/LUnix

Да что там былинного? phoronix и тот лучше тестирует. Ниочём.

отнеситеть с пониманием к тому что изначально конфиг настроен на максимальную надежность, но не производительность. 

Подбирайте параметры в конфиге в сответствии с вашим железом, интенсивностью использования БД и т.д.

ЩИТО?

ОЗУ Windows 2003 Server

Это как поясните мне неучу?

кстати да. Прикинь, делать планки оперативки со встроенной в них Windows 8 Embedded Edition?

Пишу в первую страницу былинного треда и только потом иду читать.

Не выкладывает 1С результаты внутренних тестов БД и правильно делает :) Только срач разводить.

Постгрес, кстати, достойно работает в боевых условиях (если не забыть настроить), но априори будет проигрывать скулю в параллельной работе в автоматическом режиме блокировок (привет, табличные блокировки), т.е. на большинстве текущих типовых решений. Другое дело, что ещё надо поискать внедрения, где эту разницу в производительности можно было бы прочувствовать, слишком много условий :)

о нет! главное, чтобы это сообщение не увидили в M$! Это же будет кошмар

Lunix

Воистину быдлинно.

Прикинь, делать планки оперативки со встроенной в них Windows 8 Embedded Edition?

Типун тебе на язык). Хотя если был-бы такой линукс было бы интересно поработать.

да ты знатный некрофил, тому треду 4 года уже. Да и на тот момент версии софта были далеко не последние.

еще б не падала быдлоподелка Нуралиева на этой Postrges, а то поддержку, понимаешь, заявили, а по факту - херня.

еще б не падала быдлоподелка Нуралиева на этой Postrges

Я, видимо, что-то делаю не так. Как добиться падения 1С на постгресе?

запросто. ставь 64х-битную систему, 64х-битную же платформу 8.1 и КА (базу гигов на несколько желательно). попробуй поработать. или погугли «relation tt* does not exist» релевантно 1цэ, хотя это конечно же Сурковская пропаганда.

Плюсую предыдущему оратору, эта комбинация полный П. Также наличествуют проблемы с ключами которых 1С(не хасп, а именно 1С) может не увидеть, и сверх жор памяти гигов по 25, точнее, сколько успеет из свопа отожрать =)

запросто. ставь 64х-битную систему, 64х-битную же платформу 8.1 и КА (базу гигов на несколько желательно). попробуй поработать. или погугли «relation tt* does not exist» релевантно 1цэ, хотя это конечно же Сурковская пропаганда.

Мля, а я тут собрался как раз поднимать связку Debian64 + PostgreSQL + 1C 8.2. И база у меня на 50 гигов ориентировочно будет по первому времени (там должны храниться сканы документов, они то и весят много). Режим доступа - тонкий клиент и веб клиент.

Скажите, эта связка обречена на проблемы? Стоит ли ограничиться 32-х битной платформой (тот же Debian Stable 32bit) и 4Gb ОЗУ? Интенсивность работы предполагается не сильно высокая, гдето 3-4 пользователя одновременно, только объем базы большой.

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

вроде как та ошибка специфична 8.1 на x86-64, 8.2 же развивается, может сыпать ошибками и не будет, тестить надо. попросите серверный ключик (под 64х и 32х -битные платформы) у франча, они обычно потенциальным покупателям навстречу идут. и тестировать. базу с документами, и какое-нибудь групповое проведение гонять.

(там должны храниться сканы документов, они то и весят много). Режим доступа - тонкий клиент и веб клиент.

так и храните в ФС и раздавайте ссылками веб- и тонким клиентам через веб-сервер!

вообще, лучше на мисту, я не великий спец, просто описал косяк с которым реально столкнулся.

P.S. знакомые держат базу интернет-магазина (Управление небольшой фирмой) на 8.2 под постргес и линуксом, вроде без эксцессов.

Представь себе, это для тебя арчъ, абунта, гента, а для людей линукс един.

запросто. ставь 64х-битную систему, 64х-битную же платформу 8.1 и КА

8.2 в режиме совместимости? 8.1 как бы уже давно не развивается и не поддерживается, все фиксы в составе релизов 8.2. Да и перевод на 8.2 без режима совместимости в общем случае весьма прост.

Сурковская пропаганда.

Я это не срача ради пишу, а исключительно потому, что у меня достаточно много баз c линуксовым постгресом, правда почти все на 32 битах, работают без проблем.

сверх жор памяти гигов по 25

За утечки памяти и дескрипторов на сервере взялись в последних релизах 8.2.15.х.

И база у меня на 50 гигов ориентировочно будет по первому времени (там должны храниться сканы документов, они то и весят много). Режим доступа - тонкий клиент и веб клиент.

А зачем всю эту гадость хранить непосредственно в базе? Стандартный файловый архив с томами хранения, можно из БСП выдрать, и вперёд. Месяцев так 5 назад писал свою реализацию архива под тонкого клиента, там работы примерно на день. И никаких сетевых дисков не надо.

Стоит ли ограничиться 32-х битной платформой (тот же Debian Stable 32bit) и 4Gb ОЗУ?

За глаза будет, у меня есть рабочие сервера с 2Гб и никто не жалуется. К тому же серверный ключ 64 бита в 2 раза дороже :)

А зачем всю эту гадость хранить непосредственно в базе? Стандартный файловый архив с томами хранения, можно из БСП выдрать, и вперёд. Месяцев так 5 назад писал свою реализацию архива под тонкого клиента, там работы примерно на день. И никаких сетевых дисков не надо.

Так, давай-ка поподробней.

Заливка файлов:

Файлы пользователь может класть в программу через механизм временного хранилища. На сервере файл вытаскивается из временного хранилища и кладется как файл в какую-нить директорию. Имя директории и файла запоминается в базе. Файл во временном хранилище удаляется. Правильно я все понимаю?


Получение файлов:

Получение файла в Тонком и Веб клиентах возможно через Http протокол, то есть обязательно должен быть поднят Апач. (Для Тонкого клиента Апач необязателен, но так как предполагается что будет работать и Веб клиент, то Апач нужен, пусть будет). Зная имя файла и место его хранения, программа может сформировать Http-ссылку, по которой файл будет доступен для скачивания.

И тут вопросы возникают.

1. Как в Тонком клиенте получить файл по HTTP так, чтобы он открылся «на просмотр»?

2. Как в Тонком клиенте получить файл по HTTP так, чтобы он открылся в режиме «сохранить как»?

3. Как в Веб клиенте получить файл по HTTP так, чтобы он открылся «на просмотр»?

4. Как в Веб клиенте получить файл по HTTP так, чтобы он открылся в режиме «сохранить как»?

Заливка файлов:

Да, именно так.

Получение файлов:

Проще всего в обратном порядке: прочитали файл на сервере во временное хранилище, на клиенте получили через ПолучитьФайл(), он умеет выдавать стандартный диалог с вариантами Открыть/Сохранить. Всё.

По поводу HTTP всё правильно, сформировали на сервере URL, вернули на клиента, открыли через ЗапуститьПриложение() (не проверял, но должно работать).

pgsql-8.1.5-14C

Это эталонное тормозилово же было. Пусть на 8.4.x или 9.x.x ветке посравнивает теперь.

За утечки памяти и дескрипторов на сервере взялись в последних релизах 8.2.15.х.

Ох, неужели же? А то приходилось свой костыль писать, чтобы процессы вовремя прибивать, когда у них аппетит просыпался. Очень неприятная штука.

8.2.15.301, как-то так, движение наметилось.

10099917  Количество используемых дескрипторов операционной системы
Проблема:
При работе сервера Предприятия происходит непрерывный рост количества используемых дескрипторов операционной системы.

10096674  (SW646274)  Потребление памяти менеджером кластера
Проблема:
При работе в управляемом режиме блокировки данных при наложении в длинной транзакции большого количества блокировок на одно и то же пространство происходит чрезвычайно высокий расход оперативной памяти в менеджере кластера.

Оно, тестовый .315

20003334  Объем памяти рабочего процесса кластера серверов
Проблема:
Объем памяти, занимаемой процессом rphost, непрерывно растет в процессе работы. Наиболее быстрый рост объема памяти наблюдается при наличии в кластере информационных баз с включенными регламентными заданиями, к которым не подсоединено ни одного пользователя.

О, спасибо за информацию.
Неужто починили!
Я когда-то пять лет этого ждал и не дождался. :)

Проверить только пока негде, на моих серверах не проявлялось, поэтому обходился без костылей.

У меня уже полгода, как негде проверять. :) Проявлялась не часто, но было не очень приятным.

Кстати, 8.3.1 перенесли на 20.06, интрига линуксовых клиентов сохраняется :)