Sadovnikov
v.i.p.
Э... Не многовато? Ведь, всего 20 пользователей...
Chuck_Norris
v.i.p.
Э... Не многовато? Ведь, всего 20 пользователей...ну немного ошибся, сумма будет ниже, примерно получается все так: 2х процессорный сервер HP с 4 винтами 500gb+8Gb+raid примерно выходит $3500 если добавить виндовс 2008 на 25 клиентов, то общая сумма за один комплект возрастет до $7100, еще UPS нужен будет нормальный...
Да, мое замечание по задаче - при таких объемах я бы базы разделил, одна основная крутится на одном серваке, а текущие документы вводятся на втором и регулярно за определенный период, например сутки-двое, данные из "оперативной" базы переносятся в основную
ну это как вариант
Sadovnikov
v.i.p.
Я в своих прикидках стоимость ПО не учел. Тогда да, скорее всего, соглашусь с первой цифрой.
Чайник
guru
ни о каких серваках по 250 тыр речи быть не может... все гораздо дешевле и оптимистичнее. и ни в коем случае не соглашайтесь на "две базы" - геморроя получите выше крыши.
Какие надо сервера?
Этот вопрос задавайте внедренцам. На официальном бланке предприятия.
Вы хотите у форума проект по железу получить? Так что-ли?
Ну нарисуют Вам конфигурацию, Вы с ней к директору придёте "вот мне тут на форуме насоветовали"? Возьмёте на себя такую ответственность?
"колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.
На Ваше "рас" - занимайте более чёткую и последоваательную позицию перед руководством такого плана:
"Я считаю, что рекомендованная конфигурация не сможет обеспечить нужные нам .... Для реализации поставленных задач требуется то-то...." и служебкой директору.
на Ваше "два"
никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.
А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.
А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.
Но я уже повторяюсь.
Этот вопрос задавайте внедренцам. На официальном бланке предприятия.
Вы хотите у форума проект по железу получить? Так что-ли?
Ну нарисуют Вам конфигурацию, Вы с ней к директору придёте "вот мне тут на форуме насоветовали"? Возьмёте на себя такую ответственность?
"колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.
На Ваше "рас" - занимайте более чёткую и последоваательную позицию перед руководством такого плана:
"Я считаю, что рекомендованная конфигурация не сможет обеспечить нужные нам .... Для реализации поставленных задач требуется то-то...." и служебкой директору.
на Ваше "два"
никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.
А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.
А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.
Но я уже повторяюсь.
"колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.Соглашусь. Особенно с разделением баз. Только грамотно настроить, и проблем с обменами не будет.
никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.
Sadovnikov
v.i.p.
Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...
Сейчас читают
Клин -клином вышыбают или Ура 3
150165
971
обсуждение слайдов (часть 6)
40986
438
Новогодний дозор. Круглосуточный
204501
1000
Chuck_Norris
v.i.p.
А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.Через меня прошло столько скомплектованных/ сконфигурированных серверов за последние лет 10 - Вам даже не снилось... я привел примерную конфигурацию, в конкретику на тему как и что будет сконфигурировано даже не вдавался, дабы не учить некоторых представителей контор псевдо-внедренцев...
А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.
Но я уже повторяюсь.
И как можно оценивать производительность системы, не зная как она сконфигурирована
Так что не надо ля-ля...если есть конкретные спорные моменты - озвучьте, только в привате - не хочу здесь размещать инфу...
По поводу проектов по железу и софту - я не скрываю, что оказываю по комплексной автоматизации и если мы заключаем договор письменный или устный с заказчиком, то естественно я ему предоставляю полную смету с аргументацией что надо, как и почему...
А чуть выше по поводу количества жестких дисков, их вообще пять шт. надо.. почему столько - советую поучить мат.часть по организации рейд-массивов
Chuck_Norris
v.i.p.
Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...да, конечно, но разделение баз (как они должны правильно взаимодействовать я расписывать здесь не хочу по той же причине, какая озвуче чуть выше по железу) позволит обеспечить достаточную отказоустойчивость системы, так как при таком объему ввода документов даже простой в течение 6-12 часов тянет за собой большие убытки...
iops
veteran
Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?
А по поводу организации RAID советую Вам матчасть подучить.
RAID 0 - min 2 spindel
RAID 1 - min 2 spindel
RAID 5 - min 3 spindel
RAID 10 - min 4 spindel
http://en.wikipedia.org/wiki/RAID
А по поводу организации RAID советую Вам матчасть подучить.
RAID 0 - min 2 spindel
RAID 1 - min 2 spindel
RAID 5 - min 3 spindel
RAID 10 - min 4 spindel
http://en.wikipedia.org/wiki/RAID
Chuck_Norris
v.i.p.
Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?Мериться с вами не собираюсь, все написал выше,
en.wikipedia.org/wiki/RAID
а Вы продолжайте вводить в заблуждение народ дальше... и Вам на будущее - не стОит давать народу ссылки на подобные ресурсы - там некорректной информации в разы больше чем правды...
stepan_s
veteran
господа а вы про кластеризацию не забыли? такой документоборот не редкость, да проблемы могут быть - это если не продумать сразу, но все решается и с большим документооборотом. Главное здесь что скорость записи не подкаала. Если уж совсем плохо - то можно сделать так называемое "частичное" проведение. Но повторюсь решабельно и на отличную оценку.
ТС говорил, что "сторадж" брать не собираются. Скорость записи - под вопросом. Либо сервак с большой внутренней полкой брать, шпинделей на 10 и "вперёд с песней".
при грамотном планировании и без кластеризации прожить можно.
"мутная" какая-то ситуация, поднятая ТС. То колоссальные потери, то 10 человек на документах, то "денег не хотим каждый год платить на расширение" при это и сразу "вложиться" не могут толком спланировать.
при грамотном планировании и без кластеризации прожить можно.
"мутная" какая-то ситуация, поднятая ТС. То колоссальные потери, то 10 человек на документах, то "денег не хотим каждый год платить на расширение" при это и сразу "вложиться" не могут толком спланировать.
п.9
про стораж даже намека нет. я говорил о кластеризации 1С и СУБД. И если не большой секрет откройте тайну как грамотное планирование на кластеризацию влияет
про стораж даже намека нет. я говорил о кластеризации 1С и СУБД. И если не большой секрет откройте тайну как грамотное планирование на кластеризацию влияет
рассказываю:
грамотно запланировав нужные конфигурации оборудования, для работы спецуального программного обеспечения, закупили енто оборудование. оборудование обеспечивает требуемую для бизнеса доступность в режиме 24х7х365 на протяжении 6 лет. Без кластеризации.
До данным логов доступность от 99,99, до 99,9. Ибо серверов несколько и спецуального программного обеспечения - несколько.
Бизнес - доволен.
И без дополнительных вложений в это оборудование на протяжении 6 лет.
Грамотное планирование повлияло на кластеризацию. Её нет.
грамотно запланировав нужные конфигурации оборудования, для работы спецуального программного обеспечения, закупили енто оборудование. оборудование обеспечивает требуемую для бизнеса доступность в режиме 24х7х365 на протяжении 6 лет. Без кластеризации.
До данным логов доступность от 99,99, до 99,9. Ибо серверов несколько и спецуального программного обеспечения - несколько.
Бизнес - доволен.
И без дополнительных вложений в это оборудование на протяжении 6 лет.
Грамотное планирование повлияло на кластеризацию. Её нет.
вы говорите о кластеризации железной
а я про кластеризацию програмную, причем не виртуализацию.
Если организовать кластер серверов 1С предприятия то и так называемого "планирования" нет
Но согласен что стоит обдуманно и к железному вопросу подходить.
а я про кластеризацию програмную, причем не виртуализацию.
Если организовать кластер серверов 1С предприятия то и так называемого "планирования" нет
Но согласен что стоит обдуманно и к железному вопросу подходить.
Ну много разных технологий существует.
Зачем усложнять проект?
Тем более, что дискуссия ушла куда-то в сторону. И ТС отмалчивается.
Зачем усложнять проект?
Тем более, что дискуссия ушла куда-то в сторону. И ТС отмалчивается.
п.9 Если честно это только упрощаети действительно для кого это мы 
и действительно для кого это мы Посмотрел я на сайте 1С пример внедрений. Определённо у организации ТС проблемы с пониманием задач и реализацией проекта. Ни у кого таких объёмов нет.
Как размера базы, так и кол-ва документов. Что-то в бизнес-процессах организации не так.
Картинка в аттаче.
Как размера базы, так и кол-ва документов. Что-то в бизнес-процессах организации не так.
Картинка в аттаче.
Sadovnikov
v.i.p.
А Вам не приходит в голову, что есть более крупные предприятия, чем киоски на рынках? Предприятия, в которых 4 000 отгрузок в день - это норма?
Уж извините за резкость...
Уж извините за резкость...
iops
veteran
Аттач-то смотрели? или так "постебаться"
На первой строке Аконит.
это млять ларёк что-ли?
С максимальным чилсом пользователей 370?
А размеров базы 174 Гига.
http://v8.1c.ru/overview/techparams/akonit.htm
Резкий Вы наш.
Рассмешили.
На первой строке Аконит.
это млять ларёк что-ли?
С максимальным чилсом пользователей 370?
А размеров базы 174 Гига.
http://v8.1c.ru/overview/techparams/akonit.htm
Резкий Вы наш.
Рассмешили.
Sadovnikov
v.i.p.
Тогда я несколько не понял Вашего предыдущего поста. ТС заявляет гораздо меньший документооборот.
Доброе время суток. народ подскажите не кто не сталкивался с переходом с SQL на DB2. Или возможно кто-нибудь тестировал данное ПО. Интересует прежде всего насколько лучше или хуже работает связка db2 c 1c по сравнению с SQL c 1c.Вот свежак от 1С:БИТ внедрение на DB2 . причем там бесплатная версия, которая 2 Гб памяти всего использует. У вас пользователей сколько? Возьмите workgroup - она до 16 гигабайт оперативки уже испольует и посмотрите что и как. Берете триал версии 9.7 с сайта IBM и вперед. Только db2set DB2_WORKLOAD=1C не забудьте после инсталляции сделать
fev_trsoft
junior
Мы проводили замеры, по которым можно сказать, что для документооборота 200 000 док/мес (1000 док/час) в 1С 8.1 (УПП) вполне может хватить и бесплатной DB2 Express-C, особенно если речь идет об оперативной работе.
Sadovnikov
v.i.p.
А можете описать, как Вы производили эти замеры?
Мои тесты, например, показали, что типовая УТ под скулем тихо мирно сдувается уже на первой сотне тысяч документов.
Мои тесты, например, показали, что типовая УТ под скулем тихо мирно сдувается уже на первой сотне тысяч документов.
craxx
рыжий котэ
У меня такое ощущение что это тупой пиар.
Два джуниора с одним сообщением у каждого подняли топ...
Два джуниора с одним сообщением у каждого подняли топ...
fev_trsoft
junior
Не должно такого быть, что-то не так.
Как-то делал тестовую базу УПП на 6 миллионов документов (100 гигов получилось). Заполнилась она роботами где-то за полторы недели и жила вполне адекватно. Только блокировки в управлемый режим перевел, и, понятно, проведение по партиям из оперативного режима убрал.
Поэтому не считаю размер базы критичной величиной для проведения тестов производительности.
Замеры проводили примерно так:
накатили на УПП Тест-центр, подняли нужное количество виртуальных пользователей (скажем,100), задали им минимальный интервал ввода минуты в 3, запустили, типовой сценарий Закупки,Продажа, производство в УПП, скажем, на час.
100 * (60/3) = 2000. Реально объем минимум вдвое больше, потому что у пользователя цикл документооборота не из одного документа состоит.
За неделю тестов документов каждого используемого вида в базе > 10 000 точно, не сто тысяч, конечно, но и не единицы.
Как-то делал тестовую базу УПП на 6 миллионов документов (100 гигов получилось). Заполнилась она роботами где-то за полторы недели и жила вполне адекватно. Только блокировки в управлемый режим перевел, и, понятно, проведение по партиям из оперативного режима убрал.
Поэтому не считаю размер базы критичной величиной для проведения тестов производительности.
Замеры проводили примерно так:
накатили на УПП Тест-центр, подняли нужное количество виртуальных пользователей (скажем,100), задали им минимальный интервал ввода минуты в 3, запустили, типовой сценарий Закупки,Продажа, производство в УПП, скажем, на час.
100 * (60/3) = 2000. Реально объем минимум вдвое больше, потому что у пользователя цикл документооборота не из одного документа состоит.
За неделю тестов документов каждого используемого вида в базе > 10 000 точно, не сто тысяч, конечно, но и не единицы.
fev_trsoft
junior
>типовая УТ под скулем тихо мирно сдувается
в ЦУПе не смотрели - из-за чего?
в ЦУПе не смотрели - из-за чего?
Sadovnikov
v.i.p.
Нет, не смотрел. Руки пока не дошли. Целью эксперимента было просто помотреть поведение типовой УТ на хоть каком-то объеме данных. Причины чуть позже выяснять будем, как времени немного появится.
fev_trsoft
junior
Кстати говоря. Все-таки, возможно, мы некорректно сравниваем УТ и УПП. Именно про УПП была информация, что с 1.2.15 она была очень сильно доработана на тему производительности и серьезно с тех пор на эту тему мониторится. А про УТ у меня такой информации нет.
Rondo
junior
п.9
А вы попробуйте самиExpress-C денег не просит, возьмите с сайта 1С и загрузите в нее .dt-ник.
А вы попробуйте сами
Express-C денег не просит, возьмите с сайта 1С и загрузите в нее .dt-ник.
Sadovnikov
v.i.p.
Почитайте веточку внимательно. Я на УТ-шке пробовал. Результаты, мягко говоря, не впечатлили.
Плюс, есть 2 живых примера УПП перед глазами. Не взлетают типовые конфиги от 1С на больших объемах. Увы.
Плюс, есть 2 живых примера УПП перед глазами. Не взлетают типовые конфиги от 1С на больших объемах. Увы.
Rondo
junior
п.9
Не понял на какой версии DB2 вы все это пробовали?
Не понял на какой версии DB2 вы все это пробовали?
Rondo
junior
п.9
ВО! Попробуйте поставить DB2 и посмотрите.
В ней есть один интересный алгоритм, который позволяет более эффективно строить планы запросов. План запроса перекомпилируется после того, как получены его результаты. 1С этот режим по-умолчанию использует.
ВО! Попробуйте поставить DB2 и посмотрите.
В ней есть один интересный алгоритм, который позволяет более эффективно строить планы запросов. План запроса перекомпилируется после того, как получены его результаты. 1С этот режим по-умолчанию использует.
Sadovnikov
v.i.p.
Есть у меня подозрение, что кривые запросы типовых конфигураций это не исправит...
Повторюсь - только подозрения. Не проверял.
Повторюсь - только подозрения. Не проверял.
Rondo
junior
Ну у DB2 оптимизатор хороший.Призван исправлять кривые запросы на более правильные.
Призван исправлять кривые запросы на более правильные.ТОП 5
1
2
4