Ответить в теме

не надо всех мерить по себе.

Один раз поставил, настроил и забыл навсегда.

а для нормальной работы тоже надо постараться. Да и в регионе найти такого спеца проблемно.

Однозначно линух.
Один раз поставил, настроил и забыл навсегда.
Винда годами без приложения рук - гораздо менее вероятно.
Железо может быть гораздо слабей и поэтому надежней.
Плюс еще, если в маленькой конторе "сервер" под виндой, моментально возникает соблазн съекономить и сделать еще одно рабочее место.
К чему приводит прямое попадание рядового необученого офисного работника на сервер, объяснять надо?

И кстати, "более понятная винда" очень сомнительный аргумент. Сейчас с ужесточением требований по легальности софта, заплатить админу один раз, съэкономив на к примеру "windows server 2003" - вполне реальное дело.

Для маленьких фирм - самое оно

вот такой вопрос, что проше поставить и понятнее обслужавать? В маленькой фирме без штатного системщика.

Такой результат оччевиден без тестов. вопрос давно изучен 1С-никами.

Сообщение от Naumov

Gray_bird, нашел чего сравнить...

Ну почему же. Если файл-серверная версия 1с работает на линуксе быстрей и надежней - почему бы это не замерить.
Для маленьких фирм - самое оно.

Gray_bird, нашел чего сравнить...

Просто я года 4 назад развлекался сравнением скорости 1с бух 7.7.
для 8 пользователей.
Варианты были:
dbf с файлами на windows 2000
dbf с файлами на red hat 7.2 samba 3.07
ms sql на windows 2000

Как ни странно, линух по скорости всех уделывал. Единственный минус был, традиционная беда dbf версий 1с -регулярное "переиндексируйте базу данных", которое рядовых юзеров приводит в ступор.

Закрытие месяца не смотрел.. Ведомость ОС - быстрее - порядка 1 минуты...; Карточка счета 10 - быстрее на постгре.. но там разница не большая; Полное перепроведение доков за месяц - быстрее чуть больше, чем в два раза + сервак не падает после завершения;
Samba... смысл ?.. если для 5ти человек в одном сегменте сети 1Сник поднял терминал (у бухов П4 с 512 Мб на борту, "сервер" П4 3000, 2Г - работает на пределе возможностей)... я даж не задумывался, если честно :\... Нада будет глянуть на досуге

ЗЫ: Кстати.. такая вещь вылезла - после восстановления из бекапа базы в постгре, либо замены её - ведомость ОС опять в нирвану уходит... После обсуждения этой темы с умными людьми, пришли к выводу что дело в реализации запроса - при каких то не понятных условиях (влияние планет ?.. шаманских танцев ?) запрос "прорывает", и он начинает отрабатывать за приемлемое время (те самые 4-5 минут месяц и меньше и 16 сек - январь-октябрь)... Курим тему дальше

ЗЗЫ: И ещё ) при переходе на postgre 8.2 тот ругается на неправильное использование "\\" -> этого в доке 1С нет.. как и нет того, что 8.2 базы инициализирует по другому .. незачОт По скорости 8.2 не проверял... застопорился на этой "ведомости ОС" - оно везде, сабака, висит сейчас конфу бухгалтерии обновлю - будем посмотреть;

Gray_bird, быстрей проходит, проверяли.

Сообщение от mazz

Забыл про закрытие месяца
Сейчас проверил - 8 мин. 56 сек; при описанных выше установках

Было бы очень занятным узнать сколько аналогичное закрытие происходит на файл-серверном варианте и на ms-sql варианте.
Причем файл-сервер тоже сравнить для windows и samba

Сообщение от Naumov

под Линукс позиционируется как малобюджетное решение. Для извлечение полного функционала используйте решения на MS.
Информация эта ни от кого не скрывается.
Ничего, что Постгрее сам по себе проигрывает в производительности SQL?

Так об этом и речь крупные компании без особых проблем могут позволить себе приобретение "полного" пакета, тем более у 1С на этот счет есть спец. предложение; мелким (до 12 пользователей), имхо - постгр + линух и грамотного админа... Последний им в любом случае потребуется - не долго осталось "халяве" на корпоративных компьютерах работать..Нужны комплексные решения и грамотный подход к вопросам лицензирования ПО;
Всем понятно, что 1С нет смысла кардинально изменять код в угоду повышения производительности на Postgre. Почему - я написал выше

под Линукс позиционируется как малобюджетное решение. Для извлечение полного функционала используйте решения на MS.
Информация эта ни от кого не скрывается.
Ничего, что Постгрее сам по себе проигрывает в производительности SQL?

Не удержался от флуда:
есть опыт работы с довольно крупными, в т.ч. и распределенными CRM/ERP системами на базе Lotus/Domino - все работает замечательно без костылей в виде терминалов.. Хотя, допускаю, что здесь и иное.. Это первое; второе -
компания 1С сняла бета статус с 8.1, включая реализацию платформы на Linux, описав это как "доп. возможность системы"; тем самым, Ваше заявление что "умный сисадмин должен сам переписывать закрытие месяца" в корне не верно - он за другое деньги получает и не должен искать ошибки в коде конфигурации.. 1С, вообщето, за это деньги плачены..

Забыл про закрытие месяца
Сейчас проверил - 8 мин. 56 сек; при описанных выше установках

Ok, понятно, "админы vs 1Cники" - тема для отдельного треда
Теперь по существу.
У меня тоже используется та же конфигурация что и у Mrusya, и вылезла та же проблема с ведомостью ОС.
Пришлось купить много пива и начать курить документацию по linux + PostgreSQL
При установках по умолчанию (тех, что есть в документации ) формирование ведомости по амортизации уходило в нирвану... висело до полутора часов, я потом выключил (что за месяц, что за неделю).
После погружения в мир Linux и Postgre имеем по ведомости аморт. ОС:
месяц - 4 мин 17 сек;
полная неделя - 4мин 17 сек;(!!! камень в огород 1С, дело в алгоритме выборки, скорее всего);
январь - октябрь - 15 секунд о_О... здесь я разделяю мнение камрада tomvlad'а про то, что 1С ещё не совсем готова к использованию "правильной" платформы
Что было сделано:
изменена shared memory системы:
#echo 33554432 > /proc/sys/kernel/shmmax
#echo 2097152 > /proc/sys/kernel/shmall
где:
shmmax: Maximum size of shared memory segment (bytes)
shmall: Total amount of shared memory available (bytes or pages) - для FC - pages; по ipcs -lm -> страница 4096 b
далее: в postgre.conf
shared_buffers = 13000 # 8kb each; 101 Mb.. при вызове ipcs -m говорится что postgre использует 104.6 Мб shared memory;
checkpoint_segments = 256 # 4Gb - область на HDD
checkpoint_timeout = 600
checkpoint_warning = 60
max_lock_per_transaction = 250 # в документации сказано что проверенный предел - 64.. и превзойти его практически нереально.. я превзошёл - при групповом перепроведении документов за месяц 1С вылетала с ошибкой что shared memory кончилась, postgre предложил увеличить этот параметр; (в одном из трех случаев база порушилась !!).
Кстати, в этой операции сервер быстрее файловой реализации в два раза ( 1 час 10 мин против 2 часов 27 минут). Ведомость по ОС на файловом формируется пока быстрее - за 2-3 минуты;
Т.к. бухгалтерия у меня небольшая (6 человек, с перспективой роста до 8) max_connections я уменьшил со 100 до 8, + 1 - резерв для superuser'a;
изыскания свои продолжу.. о результатах напишу
ЗЫ: Есть мнение, что postgre стоит обновить до 8.2.. у меня пока используется 8.1;
ЗЗЫ: Оперативки на сервере 1Gb (бюджет зарезали ).. И, не стоит забывать при планировании перехода - что 1С + Postgre позиционируется как решение для небольших рабочих групп, до 15 человек (1С сервер не проверяет ключ до 12 соединений... в принципе, поэтому и принято сейчас считать это порогом для такой реализации);

Да нет никакой агрессии, это раздражение, просто достало, что многие админы, которые не знают то, за что получают деньги, пытаются винить 1С в своих грехах. Я в свою очередь 1С не оправдываю, глюков хватает, но в другом. А то получается, что если руки растут из задницы (пардон), то виноват дядя. Если такой умный, то взял бы и переписал закрытие месяца.

Сообщение от tomvlad

Типовые конфигурации пока не оптимизированы под такую связку. Работать нормально будет только для самописной конфигурации, заточенной именно под Postgre. В планах 1С такая оптимизация значится только для новых редакций конфигураций. А сисадмина, который это не знает, нужно бить, и бить сильно.

Откуда столько агрессии ?... Вы же сами только что подтвердили довод админа, что всё дело в 1С
У админа задача проста - оптимизировать затраты на лицензирование ПО... а уж как это сделано, хорошо или плохо, - другое дело
ИМХО - в случае с 1С - пустая трата денег на Win Server + построение извращений с терминалами в случае небольших компаний.. У крупных с приобретением Win Server + MS SQL проблем, как правило, не возникает... Мне хочется надеятся что ребята из 1С хорошо отработают связку nix + PostgreSQL.

Я это уже делала скорость разная. Не серверный вариант формируется быстрее. Разница в количестве ОС, у нас их просто очень много около 7000 шт. На сервере до 100 - 150 шт обрабатывает достаточно прилично, а вот например 1000 вообще не дождаться.
Не серверный вариант обрабатывает и 7000 ОС достаточно быстро где-то 2 максисум 3 минуты.

самое простое, сделайте копию не серверный вариант и сравните скорость.

Большое спасибо.

Типовые конфигурации пока не оптимизированы под такую связку. Работать нормально будет только для самописной конфигурации, заточенной именно под Postgre. В планах 1С такая оптимизация значится только для новых редакций конфигураций. А сисадмина, который это не знает, нужно бить, и бить сильно.

Почему не работает?
А мне он доказывает с пеной у рта, что должно работать, мол причина в 1С-ке.

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

Здравствуйте!
У меня 1С:Предприятие 8.1 (8.1.8.76)
Бухгалтерия предприятия, редакция 1.5 (1.5.17.3)
клиент- серверный вариант
Сам сервер linux-овый.
У меня медленно формируются отчеты по основным средствам, а именно ведомость поамортизации ОС и документ закрытие месяца. В чем проблеммы не могу разобраться, может кто нибудь сталкивался с подобными случаями?