отнеситеть с пониманием к тому что изначально конфиг настроен на максимальную надежность, но не производительность.
Подбирайте параметры в конфиге в сответствии с вашим железом, интенсивностью использования БД и т.д.
Не выкладывает 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 битах, работают без проблем.
И база у меня на 50 гигов ориентировочно будет по первому времени (там должны храниться сканы документов, они то и весят много). Режим доступа - тонкий клиент и веб клиент.
А зачем всю эту гадость хранить непосредственно в базе? Стандартный файловый архив с томами хранения, можно из БСП выдрать, и вперёд. Месяцев так 5 назад писал свою реализацию архива под тонкого клиента, там работы примерно на день. И никаких сетевых дисков не надо.
Стоит ли ограничиться 32-х битной платформой (тот же Debian Stable 32bit) и 4Gb ОЗУ?
За глаза будет, у меня есть рабочие сервера с 2Гб и никто не жалуется. К тому же серверный ключ 64 бита в 2 раза дороже :)
А зачем всю эту гадость хранить непосредственно в базе? Стандартный файловый архив с томами хранения, можно из БСП выдрать, и вперёд. Месяцев так 5 назад писал свою реализацию архива под тонкого клиента, там работы примерно на день. И никаких сетевых дисков не надо.
Так, давай-ка поподробней.
Заливка файлов:
Файлы пользователь может класть в программу через механизм временного хранилища. На сервере файл вытаскивается из временного хранилища и кладется как файл в какую-нить директорию. Имя директории и файла запоминается в базе. Файл во временном хранилище удаляется. Правильно я все понимаю?
Получение файлов:
Получение файла в Тонком и Веб клиентах возможно через Http протокол, то есть обязательно должен быть поднят Апач. (Для Тонкого клиента Апач необязателен, но так как предполагается что будет работать и Веб клиент, то Апач нужен, пусть будет). Зная имя файла и место его хранения, программа может сформировать Http-ссылку, по которой файл будет доступен для скачивания.
И тут вопросы возникают.
1. Как в Тонком клиенте получить файл по HTTP так, чтобы он открылся «на просмотр»?
2. Как в Тонком клиенте получить файл по HTTP так, чтобы он открылся в режиме «сохранить как»?
3. Как в Веб клиенте получить файл по HTTP так, чтобы он открылся «на просмотр»?
4. Как в Веб клиенте получить файл по HTTP так, чтобы он открылся в режиме «сохранить как»?
Проще всего в обратном порядке: прочитали файл на сервере во временное хранилище, на клиенте получили через ПолучитьФайл(), он умеет выдавать стандартный диалог с вариантами Открыть/Сохранить. Всё.
По поводу HTTP всё правильно, сформировали на сервере URL, вернули на клиента, открыли через ЗапуститьПриложение() (не проверял, но должно работать).
10099917 Количество используемых дескрипторов операционной системы
Проблема:
При работе сервера Предприятия происходит непрерывный рост количества используемых дескрипторов операционной системы.
10096674 (SW646274) Потребление памяти менеджером кластера
Проблема:
При работе в управляемом режиме блокировки данных при наложении в длинной транзакции большого количества блокировок на одно и то же пространство происходит чрезвычайно высокий расход оперативной памяти в менеджере кластера.
20003334 Объем памяти рабочего процесса кластера серверов
Проблема:
Объем памяти, занимаемой процессом rphost, непрерывно растет в процессе работы. Наиболее быстрый рост объема памяти наблюдается при наличии в кластере информационных баз с включенными регламентными заданиями, к которым не подсоединено ни одного пользователя.