2(38) Полу-типовая (никаких серьезных изменений в ядре) БП прошлого поколения. На этой фактически типовой БП сервера пытались нарастить - в памяти, в дисках - эффект - ноль. Скорость проведения документов растет незначительно. Ну 10% максимум. Платформа - последняя версия 8.2. Уж не скажешь ли ты, что нужно платформу менять? Тут люди уже sql сервера купили, а прироста производительности нет. Она как будто спит.

2(39) Это ни о чем.

[url]http://www.youtube.com/watch?v=qLlTNsGaGKk[/url]

+(43) Буду Деймсом [url]http://www.youtube.com/watch?v=ripzvbVmqxw[/url]

статья такая пустышка, как и столбик.

пернул товарисЧ - оказалось, ни о чем, да и то пальцем в небо

2(45) Ну ты продолжи свои мысли. О чем они?

[quote=Моррисон;30879366]Полу-типовая[/quote]
[quote=Моррисон;30879366]Она как будто спит.[/quote]

Ну и что это за детский лепет? Где замеры производительности? Где логи технологического журнала? Где журналы производительности ОС?

Я уже 2-й месяц совокупляюсь с платформой - творческие люди попросили АРМ состряпать. Список потребностей на 80% покрывался УФ. В результате получил лютые тормоза самой формы при передаче контекста между клиентом и сервером. Ну так я и решаю проблему на всех трех уровнях сейчас: замеры 1С, технологический журнал 1С, profiler. И вот ты ж гляди, задержку с 7 секунд до 0,2 сбил.

А теперь глянь на себя: "незначительно... как будто...". Естественно, когда нелокализованную проблему пытаются накрыть ковровым бомбометанием дисками, удар придется по всему, что лежит на поверхности, а суть как была в бункере, так и останется. Хотели бы решать - уже бы решили. А то, что бабла на железки угробили - так только потому, что разбираться в проблеме было лениво. Лучше б специалистам заплатили.

2(47) Ну ты просто протестируй. И ты убедишься. Просто убедишься, что диски не нагружены, памяти достаточно, процессоры в норме. Я уже заявку подал в свое время, на увеличение мощности, сейчас она будет исполнена, и получим [filolog]бльять[/filolog] сервер со стендов. Но понимаешь в чем дело - 1с никак не масштабируется. Вообще никак. Хоть ты закупай мэнфрэймы (я больше чем уверен ты знаешь о них понаслышке) 1С будет спать. Вопрос - почему она спит? Нам нужно быстрое проведение документов, ничего особенного - БП 1.6. Толстый клиент на уровне сервера приложений.

+2(47) Творческие люди... привет творческим людям.

+(49) Кластерные индексы не приплетай. Мощность серверов увеличивается - выхлоп - ноль. Как это возможно?

50-Моррисон > Да элементарно. Достаточно банальных транзакционных блокировок. Зачет авансов, партионный учет, учет УСН передают привет горячий и выстраивают пользователей в линию. А когда все они встанут в очередь на блокировках - да хоть усыпься дисками, легче от этого никому не станет. И это самый банальный пример. Еще раз повторяю: чтобы решить проблему - ее нужно сначала определить. А если идти "куда-то" то окажешься "где-то". И не надо винить никого в том, что твои ожидания не совпали с реальностью - надо было дорогу узнавать, а не тащиться куда попало.

С одно

Тьфу блин. :)
С одной стороны я согласен с Рипером - конечно нужно замерять и искать узкие места, но с другой стороны понимаю о чем говорит моррисон.
Ну вот измерили мы, ну убедились что это транзакционные блокировки. и? Переписать типовой код чтобы минимизировать блокировки? Не вариант - нужно сохранить поддержку. А с платформой 1с ничего не делает. До сих пор нет х64 толстого клиента, нормально не поддерживается многопроцессорность и т.п. Поэтому и остается разводить логи и базу на разные диски, ставить ссд, переводить пользователей в терминал. т.е. играться железом.

(51) опять ты путаешь
зачет авансов, партионный учет, учет УСН передают прЕвЕд горячий разработчикам - 1це всегда отличалась безграмотностью алгоритмов прикладной части.
безграмотность алгоритмов, будучи соединенной с джамшутовой реализацией - и дают эффект ... (не пропускает цензура, в общем улица красных фонарей)

именно поэтому даже просто элементарное переписывание кода с исправлением косяков реализации дает столь значимый эффект в плане скорости и масштабируемости. Превед джамшутам!!!!

о масштабируемости можно говорить, когда достал из коробки и работает в 90% организаций
а когда в каждой второй размером с 2 ларька с шаурмой нужно допиливать - просто распиаренное г...

по стоимости напяливания типовых конф 1це от 50 мест уже давно во много раз обогнала все. просто эта стоимость размазана по времени и видам затрат

53-Wit > Ты тоже красавец, чуть что - сразу переписать. А возможность того, что там косяки в данных или настройках мы не рассматриваем?

(56) Собственно в 54 раскрыта дальше моя мысль. Есс-но не чуть-что, а там где это нужно. Не совсем понял мысль, как косяки в данных влияют на скорость работы? косяки там или нет - это сугубо личное восприятие пользователя, для бездушной машины данные либо есть, либо их нет.

(57) косяки в данных - это тоже может быть
в результате расчет м.б. либо неверным, либо неточным

но косяки - это тоже результат недоработок разработчиков, ибо

- делать проверки на ошибочный ввод очень затратно для разработчиков. Проще свалить проверку на "тупого" юзера и орать про его невнимательность.
учитывая, что ошибочных ситуаций м.б. много .....

- поддерживать механизмы контроля вводимых данных при обновлениях тоже затратно.

- с точки зрения разработчиков нафиг все проверки - работать будет быстрей.

- и так далее

надо быть честной до конца - отсутствие проверок при вводе данных присуще не только 1це, но и многим другим системам. В той или иной степени. хотя в 1це они просто злобно отсутствуют как класс

37-Моррисон > это проблема не только 1С, а впервую очередь ОСи.
1Ска не создаёт насильственно файл подкачки. Это ОСь определяет по "каким-то" параметрам объём занимаемой оперативки и размещает файл подкачки на диске. и СУБД тут тоже ни причём (имхо, но так - пока мне докажут обратного).

59-Helen1986 > если 1С сделает проверку данных на ввод, то франчи станут просто не нужны клиентам. но при этом 1С скатится до уровня ИПшника, торгующего софтом через интернет.
ну будут и косвенные проблемы - типа а мы хотим не так, а вот так (покупатели/пользователи) - т.е. неприятие 1Са ибо гибкость потеряется.
а соответственно появятся "специалисты", которые будут отключать проверку данных (и в принципе всё). а через какое то время после "отключения". клиенты будут покупать другой ПП, но уже не у 1С.

61+ а сейчас так: мы не ограничиваем ваши возможности по работе с нашим ПО, и предоставляем вам разветвлённую партнерскую сеть для решения любых проблем и вопросов.

поправочка. конечно, "не ограничиваем" - в рамках лицензионного соглашения. но свобода достаточная.
а партнёрская сеть 1Са - пожалуй самая крупная среди производителей подобного ПО. и это статус, на котором держатся продажи ПО 1С, не в последнюю очередь.

а что до защиты от дурака - так все дураки разные. и от конкретных дураков смогёт лучше всего помочь конкретный партнёр на месте.

(64) в типовых - конфигурация дураков тоже типовая и 70%-90% ошибок ТОЖЕ типовые (одинаковые

(61) гибкость не потеряется. все останется точно таким же - на то они и франчи для доработок

(62) любые вопросы франчи не решают.

(60) скуль (МС) зватает столько памяти, сколько может (или сколько разрешено) и сам внутри ею управляет. Система и ее своп здесь отдыхают

1111111

2(51) Ну хорошо. Перевел базу в режим версионности записей. Получил уменьшение блокировок. Скорость выросла - незначительно. Проверено - два потока мощного проведения документов - живет, третий кладется в блокировках. Увеличил время ожидания захвата таблиц до 2 минут. Третий поток не дает такого количества блокировок - скорость фактически не растет. Разве что, пользователи могут работать во время мощного проведения документов. Ну и чего?

2(60) "и СУБД тут тоже ни причём" - не буду врать - при третьем потоке проведения блокировки на стороне sql видны. Это уже в режиме версионности. Эксперименты в обычном режиме я уже ставить не буду.

+(68) По поводу скуля Helen1986 абсолютно права. Он жрет , пока не выжрет, когда выжрет - получаем дикое торможение.

2(Reaper) Кстати, Reaper, попробуй выполнить запись в базу, в регистр бухгалтерии с субконто, которые не принадлежат, два-три раза даст - после этого служба аварийно завершиться. И вот почему он так себя ведет - объяснишь?

2(47) "А то, что бабла на железки угробили - так только потому, что разбираться в проблеме было лениво. Лучше б специалистам заплатили." - прости, что не ответил сразу на твое высказывание. Здесь собраны очень неплохие специалисты. А службы падают тем не менее аварийно. Просто тебе объем сложно представить. Ты мыслишь всякой франчевой херотой, как я в свое время наслушался от технического директора во франче.

2(60) "параметрам объём занимаемой оперативки и размещает файл подкачки на диске. и СУБД тут тоже ни причём"

Зелёный тролль, да оперативка вообще не нагружена, там 96 гигов стоит и ось не использует их полностью, то есть нет проблем с памятью. Зеленый тролль, ну хочу уколоть, чтобы просто на будущее знал - пишется так - не при чем.

2(53) " но с другой стороны понимаю о чем говорит моррисон"

Wit, а меня за что написал с маленькой буквы?

2(56) "Ты тоже красавец, чуть что - сразу переписать. А возможность того, что там косяки в данных или настройках мы не рассматриваем? " - Reaper, у меня логика простая - добавили мощности железа, добавили мощности серверу приложений 1С, но он из не ИСПОЛЬЗУЕТ. Понимаешь или нет? Вот тот скуль от мс жрет все, что под руку попадается и мощность у него растет. Вот и все, все очень просто.

+(72) Тьфу, по Фрейду наверное оговорился - "ну хочу уколоть", не хочу уколоть само собой.