| 0
- 13.06.2013 - 08:00
|
Доброго времени суток уважаемые! Нужен совет вот по какому вопросу: Есть распределенка, данные из периферийных баз сливаются в центральную. Из центральной только конфа и некоторые справочники. Обмен происходит раз в сутки. В одной из периферийных баз перепроводили документы интенсивно, файл выгрузки получился около 650Мб незапакованный. Так вот проблема - при загрузке этого файла, когда начинают загружаться проводки по НУ резко падает скорость. Причем не сразу, несколько сотен проводок загружаются нормально, а потом время между двумя загрузками по 10-15 минут. Это видно в ЖР (могу скрин кинуть). файл такого объема загружаю не первый раз. Раньше таких проблем не наблюдалось. С какого момента возникла эта проблема не отфиксировал, но никаких действий с сервером и софтом не производилось (кроме обновления конфы в 1с, обновления антивируса и установки обновлений на винду). Конфа - КА последняя редакция, платформа - 8.2.18.61 Сервер - PostgreSQL 9.1.2-1.1C(x64) с оф сайта 1с. настройки типовые по инструкции. База в файловой версии была около 17Гб. Но на файловой версии очень медленно происходила загрузка как раз проводок по НУ (в принципе все проводки медленно загружались), поэтому перенесли базу на постгри, стало гораздо быстрее работать, пока не возникла проблема. ТИИ делал - не помогло.     | | ||
| 41
- 15.06.2013 - 21:25
| 2(38) Полу-типовая (никаких серьезных изменений в ядре) БП прошлого поколения. На этой фактически типовой БП сервера пытались нарастить - в памяти, в дисках - эффект - ноль. Скорость проведения документов растет незначительно. Ну 10% максимум. Платформа - последняя версия 8.2. Уж не скажешь ли ты, что нужно платформу менять? Тут люди уже sql сервера купили, а прироста производительности нет. Она как будто спит. | | ||
| 42
- 15.06.2013 - 22:24
| 2(39) Это ни о чем. | | ||
| 43
- 15.06.2013 - 22:36
| http://www.youtube.com/watch?v=qLlTNsGaGKk | | ||
| 44
- 15.06.2013 - 22:44
| +(43) Буду Деймсом http://www.youtube.com/watch?v=ripzvbVmqxw | | ||
| 45
- 15.06.2013 - 23:39
|
статья такая пустышка, как и столбик. пернул товарисЧ - оказалось, ни о чем, да и то пальцем в небо | | ||
| 46
- 15.06.2013 - 23:48
| 2(45) Ну ты продолжи свои мысли. О чем они? | | ||
| 47
- 15.06.2013 - 23:49
| Цитата:
Цитата:
Я уже 2-й месяц совокупляюсь с платформой - творческие люди попросили АРМ состряпать. Список потребностей на 80% покрывался УФ. В результате получил лютые тормоза самой формы при передаче контекста между клиентом и сервером. Ну так я и решаю проблему на всех трех уровнях сейчас: замеры 1С, технологический журнал 1С, profiler. И вот ты ж гляди, задержку с 7 секунд до 0,2 сбил. А теперь глянь на себя: "незначительно... как будто...". Естественно, когда нелокализованную проблему пытаются накрыть ковровым бомбометанием дисками, удар придется по всему, что лежит на поверхности, а суть как была в бункере, так и останется. Хотели бы решать - уже бы решили. А то, что бабла на железки угробили - так только потому, что разбираться в проблеме было лениво. Лучше б специалистам заплатили. | | ||
| 48
- 16.06.2013 - 00:48
| 2(47) Ну ты просто протестируй. И ты убедишься. Просто убедишься, что диски не нагружены, памяти достаточно, процессоры в норме. Я уже заявку подал в свое время, на увеличение мощности, сейчас она будет исполнена, и получим [*****] сервер со стендов. Но понимаешь в чем дело - 1с никак не масштабируется. Вообще никак. Хоть ты закупай мэнфрэймы (я больше чем уверен ты знаешь о них понаслышке) 1С будет спать. Вопрос - почему она спит? Нам нужно быстрое проведение документов, ничего особенного - БП 1.6. Толстый клиент на уровне сервера приложений. | | ||
| 49
- 16.06.2013 - 00:49
| +2(47) Творческие люди... привет творческим людям. | | ||
| 50
- 16.06.2013 - 01:03
| +(49) Кластерные индексы не приплетай. Мощность серверов увеличивается - выхлоп - ноль. Как это возможно? | | ||
| 51
- 16.06.2013 - 01:37
| 50-Моррисон > Да элементарно. Достаточно банальных транзакционных блокировок. Зачет авансов, партионный учет, учет УСН передают привет горячий и выстраивают пользователей в линию. А когда все они встанут в очередь на блокировках - да хоть усыпься дисками, легче от этого никому не станет. И это самый банальный пример. Еще раз повторяю: чтобы решить проблему - ее нужно сначала определить. А если идти "куда-то" то окажешься "где-то". И не надо винить никого в том, что твои ожидания не совпали с реальностью - надо было дорогу узнавать, а не тащиться куда попало. | | ||
| 52
- 16.06.2013 - 05:35
| С одно | | ||
| 53
- 16.06.2013 - 05:41
|
Тьфу блин. :) С одной стороны я согласен с Рипером - конечно нужно замерять и искать узкие места, но с другой стороны понимаю о чем говорит моррисон. Ну вот измерили мы, ну убедились что это транзакционные блокировки. и? Переписать типовой код чтобы минимизировать блокировки? Не вариант - нужно сохранить поддержку. А с платформой 1с ничего не делает. До сих пор нет х64 толстого клиента, нормально не поддерживается многопроцессорность и т.п. Поэтому и остается разводить логи и базу на разные диски, ставить ссд, переводить пользователей в терминал. т.е. играться железом. | | ||
| 54
- 16.06.2013 - 09:45
|
(51) опять ты путаешь зачет авансов, партионный учет, учет УСН передают прЕвЕд горячий разработчикам - 1це всегда отличалась безграмотностью алгоритмов прикладной части. безграмотность алгоритмов, будучи соединенной с джамшутовой реализацией - и дают эффект ... (не пропускает цензура, в общем улица красных фонарей) именно поэтому даже просто элементарное переписывание кода с исправлением косяков реализации дает столь значимый эффект в плане скорости и масштабируемости. Превед джамшутам!!!! о масштабируемости можно говорить, когда достал из коробки и работает в 90% организаций а когда в каждой второй размером с 2 ларька с шаурмой нужно допиливать - просто распиаренное г... | | ||
| 55
- 16.06.2013 - 09:48
| по стоимости напяливания типовых конф 1це от 50 мест уже давно во много раз обогнала все. просто эта стоимость размазана по времени и видам затрат | | ||
| 56
- 16.06.2013 - 10:54
| 53-Wit > Ты тоже красавец, чуть что - сразу переписать. А возможность того, что там косяки в данных или настройках мы не рассматриваем? | | ||
| 57
- 16.06.2013 - 12:47
| (56) Собственно в 54 раскрыта дальше моя мысль. Есс-но не чуть-что, а там где это нужно. Не совсем понял мысль, как косяки в данных влияют на скорость работы? косяки там или нет - это сугубо личное восприятие пользователя, для бездушной машины данные либо есть, либо их нет. | | ||
| 58
- 16.06.2013 - 13:04
|
(57) косяки в данных - это тоже может быть в результате расчет м.б. либо неверным, либо неточным но косяки - это тоже результат недоработок разработчиков, ибо - делать проверки на ошибочный ввод очень затратно для разработчиков. Проще свалить проверку на "тупого" юзера и орать про его невнимательность. учитывая, что ошибочных ситуаций м.б. много ..... - поддерживать механизмы контроля вводимых данных при обновлениях тоже затратно. - с точки зрения разработчиков нафиг все проверки - работать будет быстрей. - и так далее | | ||
| 59
- 16.06.2013 - 13:14
| надо быть честной до конца - отсутствие проверок при вводе данных присуще не только 1це, но и многим другим системам. В той или иной степени. хотя в 1це они просто злобно отсутствуют как класс | | ||
| 60
- 16.06.2013 - 22:56
|
37-Моррисон > это проблема не только 1С, а впервую очередь ОСи. 1Ска не создаёт насильственно файл подкачки. Это ОСь определяет по "каким-то" параметрам объём занимаемой оперативки и размещает файл подкачки на диске. и СУБД тут тоже ни причём (имхо, но так - пока мне докажут обратного). | | ||
| 61
- 16.06.2013 - 23:05
|
59-Helen1986 > если 1С сделает проверку данных на ввод, то франчи станут просто не нужны клиентам. но при этом 1С скатится до уровня ИПшника, торгующего софтом через интернет. ну будут и косвенные проблемы - типа а мы хотим не так, а вот так (покупатели/пользователи) - т.е. неприятие 1Са ибо гибкость потеряется. а соответственно появятся "специалисты", которые будут отключать проверку данных (и в принципе всё). а через какое то время после "отключения". клиенты будут покупать другой ПП, но уже не у 1С. | | ||
| 62
- 16.06.2013 - 23:06
| 61+ а сейчас так: мы не ограничиваем ваши возможности по работе с нашим ПО, и предоставляем вам разветвлённую партнерскую сеть для решения любых проблем и вопросов. | | ||
| 63
- 16.06.2013 - 23:12
|
поправочка. конечно, "не ограничиваем" - в рамках лицензионного соглашения. но свобода достаточная. а партнёрская сеть 1Са - пожалуй самая крупная среди производителей подобного ПО. и это статус, на котором держатся продажи ПО 1С, не в последнюю очередь. | | ||
| 64
- 16.06.2013 - 23:13
| а что до защиты от дурака - так все дураки разные. и от конкретных дураков смогёт лучше всего помочь конкретный партнёр на месте. | | ||
| 65
- 17.06.2013 - 09:16
|
(64) в типовых - конфигурация дураков тоже типовая и 70%-90% ошибок ТОЖЕ типовые (одинаковые (61) гибкость не потеряется. все останется точно таким же - на то они и франчи для доработок (62) любые вопросы франчи не решают. (60) скуль (МС) зватает столько памяти, сколько может (или сколько разрешено) и сам внутри ею управляет. Система и ее своп здесь отдыхают | | ||
| 66
- 17.06.2013 - 11:18
| 1111111 | | ||
| 67
- 11.07.2013 - 01:51
| 2(51) Ну хорошо. Перевел базу в режим версионности записей. Получил уменьшение блокировок. Скорость выросла - незначительно. Проверено - два потока мощного проведения документов - живет, третий кладется в блокировках. Увеличил время ожидания захвата таблиц до 2 минут. Третий поток не дает такого количества блокировок - скорость фактически не растет. Разве что, пользователи могут работать во время мощного проведения документов. Ну и чего? | | ||
| 68
- 11.07.2013 - 01:54
| 2(60) "и СУБД тут тоже ни причём" - не буду врать - при третьем потоке проведения блокировки на стороне sql видны. Это уже в режиме версионности. Эксперименты в обычном режиме я уже ставить не буду. | | ||
| 69
- 11.07.2013 - 01:57
| +(68) По поводу скуля Helen1986 абсолютно права. Он жрет , пока не выжрет, когда выжрет - получаем дикое торможение. | | ||
| 70
- 11.07.2013 - 02:07
| 2(Reaper) Кстати, Reaper, попробуй выполнить запись в базу, в регистр бухгалтерии с субконто, которые не принадлежат, два-три раза даст - после этого служба аварийно завершиться. И вот почему он так себя ведет - объяснишь? | | ||
| 71
- 11.07.2013 - 02:11
| 2(47) "А то, что бабла на железки угробили - так только потому, что разбираться в проблеме было лениво. Лучше б специалистам заплатили." - прости, что не ответил сразу на твое высказывание. Здесь собраны очень неплохие специалисты. А службы падают тем не менее аварийно. Просто тебе объем сложно представить. Ты мыслишь всякой франчевой херотой, как я в свое время наслушался от технического директора во франче. | | ||
| 72
- 20.07.2013 - 16:09
|
2(60) "параметрам объём занимаемой оперативки и размещает файл подкачки на диске. и СУБД тут тоже ни причём" Зелёный тролль, да оперативка вообще не нагружена, там 96 гигов стоит и ось не использует их полностью, то есть нет проблем с памятью. Зеленый тролль, ну хочу уколоть, чтобы просто на будущее знал - пишется так - не при чем. | | ||
| 73
- 20.07.2013 - 16:11
|
2(53) " но с другой стороны понимаю о чем говорит моррисон" Wit, а меня за что написал с маленькой буквы? | | ||
| 74
- 20.07.2013 - 16:20
| 2(56) "Ты тоже красавец, чуть что - сразу переписать. А возможность того, что там косяки в данных или настройках мы не рассматриваем? " - Reaper, у меня логика простая - добавили мощности железа, добавили мощности серверу приложений 1С, но он из не ИСПОЛЬЗУЕТ. Понимаешь или нет? Вот тот скуль от мс жрет все, что под руку попадается и мощность у него растет. Вот и все, все очень просто. | | ||
| 75
- 20.07.2013 - 16:25
| +(72) Тьфу, по Фрейду наверное оговорился - "ну хочу уколоть", не хочу уколоть само собой. | |
Интернет-форум Краснодарского края и Краснодара |
