LINUX.ORG.RU

ОЗУ Windows 2003 Server

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

ОЗУ Windows

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

ymuv ★★★★ ()

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

anonymoos ★★★★ ()

ОС Lunix

Прекрасно.

Deleted ()

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

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

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

ЩИТО?

stevejobs ★★★☆☆ ()
Ответ на: комментарий от ymuv

ОЗУ Windows 2003 Server

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

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

stevejobs ★★★☆☆ ()

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

red_eyed_peguin ()

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

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

ollowtf ★★★ ()
Ответ на: комментарий от stevejobs

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

OldWiseCat ★★ ()

Lunix

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

kranky ★★★★★ ()
Ответ на: комментарий от stevejobs

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

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

ymuv ★★★★ ()

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

nu11 ★★★★★ ()

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

anon1984 ()
Ответ на: комментарий от anon1984

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

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

ollowtf ★★★ ()
Ответ на: комментарий от ollowtf

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

anon1984 ()
Ответ на: комментарий от ollowtf

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

GAMer ★★★★★ ()
Ответ на: комментарий от anon1984

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

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

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

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

anon1984 ()
Ответ на: комментарий от Deleted

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

J ★★★★ ()
Ответ на: комментарий от anon1984

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

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

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

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

ollowtf ★★★ ()
Ответ на: комментарий от GAMer

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

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

ollowtf ★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

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

ollowtf ★★★ ()
Ответ на: комментарий от ollowtf

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

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

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

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


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

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

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

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

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

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

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

ollowtf ★★★ ()

pgsql-8.1.5-14C

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

imul ★★★★★ ()
Ответ на: комментарий от ollowtf

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

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

imul ★★★★★ ()
Ответ на: комментарий от imul

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

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

ollowtf ★★★ ()
Ответ на: комментарий от imul

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

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

ollowtf ★★★ ()
Ответ на: комментарий от ollowtf

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

imul ★★★★★ ()
Ответ на: комментарий от imul

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

ollowtf ★★★ ()
Ответ на: комментарий от ollowtf

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

imul ★★★★★ ()
Ответ на: комментарий от imul

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

ollowtf ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.