Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
jumbo frames+изменение размера сетевого пакета SQL каким образом будет влиять на производительность?
Сетевой пакет SQL в общем случае microsoft трогать не рекомендует, в MSDN нет информации по его настройке. Только курсы.
Jumbo frames в общем случае уменьшат количество OP/S на сетевом интерфейсе, уменьшив overhead на заголовки пакетов в несколько раз. Правда, как я недавно читал, относительно пропускной способности канала этот overhead упадет примерно с 10 до 4 процентов, не больше. В SQL обычно как раз в op/s на интерфейсе упор и происходит, а не в общую пропускную способность, потому jumbo frames должны несколько увеличивать пропускную способность интерфейса.
Jumbo frames в общем случае уменьшат количество OP/S на сетевом интерфейсе, уменьшив overhead на заголовки пакетов в несколько раз. Правда, как я недавно читал, относительно пропускной способности канала этот overhead упадет примерно с 10 до 4 процентов, не больше. В SQL обычно как раз в op/s на интерфейсе упор и происходит, а не в общую пропускную способность, потому jumbo frames должны несколько увеличивать пропускную способность интерфейса.
Почитал малехо по этим Джамбо-кадрам
видимо с ними не все так радужно… в сетях Ethernet.
Вот бы заюзать в 1С родной протокол Infiniband + RDMA (англ. Remote Direct Memory Access — удалённый прямой доступ к памяти)… вот это бы было интересно посмотреть)))
Как правило, не превышают 9000 байт, поскольку в сетях Ethernet используется 32-битная CRC, которая теряет свою эффективность при объеме данных больше 12000 байт; к тому же 9000 байт вполне достаточно для передачи 8-килобайтной датаграммы
видимо с ними не все так радужно… в сетях Ethernet.
Вот бы заюзать в 1С родной протокол Infiniband + RDMA (англ. Remote Direct Memory Access — удалённый прямой доступ к памяти)… вот это бы было интересно посмотреть)))
Кстати в свое время я спорил со спецами фирмы SoftPoint по поводу влияния сети на работу платформы 1С.
Они активно утверждали что нет такого сильного влияния)))
похоже передумали)) гыыыыы
Цитата с их сайта: www.softpoint.ru/article_id4226.htm
Они активно утверждали что нет такого сильного влияния)))
похоже передумали)) гыыыыы
Цитата с их сайта: www.softpoint.ru/article_id4226.htm
Вывод
В учетных системах наравне с пропускной способностью огромное значение имеет параметр, определяющий отклик сети, на который часто не обращают внимание.
внимательней читайте, над графиком
если не видно в цитате выделяю отдельно «MS SQ с 1С обмен идет пакетами 4 кб»
Ethernet Gigabit на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб)
если не видно в цитате выделяю отдельно «MS SQ с 1С обмен идет пакетами 4 кб»
Вы путаетесь в показаниях.
4кб — размер пакета SQL сервера.
Если в сети не включены jumbo frames, то на tcp уровне он уже побьется на 1472 байта, и фрагментами дойдет до получателя.
График, насколько я понимаю, как раз для размера TCP пакета и не имеет отношения к размеру пакета SQL server.
Попингуйте соседа из командной строки
ping -l 1472 -f 172.30.100.219
ping -l 1476 -f 172.30.100.219
ping -l 4000 -f 172.30.100.219
и сами все увидите. -f запрещает фрагментацию пакета, и вы тем самым найдете максимальный размер пакета на уровне icmp (MTU — icmp header). На TCP он будет отличаться на пару байт.
Тем не менее накладные расходы возникают как на сетевом уровне (заголовки TCP), так и на прикладном (SQL-пакет). SQL пакет фрагментируется в более мелкие, и они действительно добавляют проблем. Однако, есть нюанс: нормально спроектированное приложение этого не замечает. Потому что любая клиент-серверная архитектура подразумевает подход «разделяй и властвуй»: клиент должен получить необходимый минимум данных. Обработку огромного массива должен вести сервер. Судя по всему, в 1С это не так.
Конкретно пример моей организации: до позапрошлой недели с 700 пользователями справлялся один 8-ядерный SQL-server, который на прошлых выходных успешно мигрировал в 20-ядерный — превентивный переезд.
Все пользователи работают через один 2х-гигабитный транк. Кроме того, сервер еще успешно обновляет read-only реплику (раньше обновлял mirror), через те же два гигабита. Один гигабит действительно был перегружен, именно по количеству IOPS а не по пропускной способности.
Мне все эти экзерсисы (DOP=1, постоянная реиндексация, борьба с логами и т.п.) говорят только об одном: SQL server используется не по назначению. Те, кто его использует, имеют общее представление что такое SQL, однако почитать значение этих параметров, на что они влияют, что может пойти не так и как это «не так» потом вылечить не удосуживаются, тупо следуя рекомендациям с форумов. Отправьте пару специалистов по 1С на курсы по MS SQL, вы очень удивитесь их последующей результативности.
4кб — размер пакета SQL сервера.
Если в сети не включены jumbo frames, то на tcp уровне он уже побьется на 1472 байта, и фрагментами дойдет до получателя.
График, насколько я понимаю, как раз для размера TCP пакета и не имеет отношения к размеру пакета SQL server.
Попингуйте соседа из командной строки
ping -l 1472 -f 172.30.100.219
ping -l 1476 -f 172.30.100.219
ping -l 4000 -f 172.30.100.219
и сами все увидите. -f запрещает фрагментацию пакета, и вы тем самым найдете максимальный размер пакета на уровне icmp (MTU — icmp header). На TCP он будет отличаться на пару байт.
Тем не менее накладные расходы возникают как на сетевом уровне (заголовки TCP), так и на прикладном (SQL-пакет). SQL пакет фрагментируется в более мелкие, и они действительно добавляют проблем. Однако, есть нюанс: нормально спроектированное приложение этого не замечает. Потому что любая клиент-серверная архитектура подразумевает подход «разделяй и властвуй»: клиент должен получить необходимый минимум данных. Обработку огромного массива должен вести сервер. Судя по всему, в 1С это не так.
Конкретно пример моей организации: до позапрошлой недели с 700 пользователями справлялся один 8-ядерный SQL-server, который на прошлых выходных успешно мигрировал в 20-ядерный — превентивный переезд.
Все пользователи работают через один 2х-гигабитный транк. Кроме того, сервер еще успешно обновляет read-only реплику (раньше обновлял mirror), через те же два гигабита. Один гигабит действительно был перегружен, именно по количеству IOPS а не по пропускной способности.
Мне все эти экзерсисы (DOP=1, постоянная реиндексация, борьба с логами и т.п.) говорят только об одном: SQL server используется не по назначению. Те, кто его использует, имеют общее представление что такое SQL, однако почитать значение этих параметров, на что они влияют, что может пойти не так и как это «не так» потом вылечить не удосуживаются, тупо следуя рекомендациям с форумов. Отправьте пару специалистов по 1С на курсы по MS SQL, вы очень удивитесь их последующей результативности.
Немного не по теме, но у меня ( и еще пары моих знакомых) есть такая проблема. Файл лога SQL растет сумасшедшими темпами. Приходится регулярно переводить базу SQL в режим Simple и делать shrink файла лога. Мой вариант такой. Есть Торговля объемом 20 гб, рост лог файла до 140 гб за 2 недели. Рост происходит ночью примерно на объем базы. В чем причина и как бороться?
Мда…
А в документации к SQL server вообще-то пишут, что лог шринкуется только если его бекапить. Есть плохой способ, гуглить надо backup to null. Нормальные человеки в продакшне его не используют. Есть нормальный, просто бекап на диск или ленточку.
А вообще — зачем вам full? В simple он будет использоваться повторно без бекапов.
А в документации к SQL server вообще-то пишут, что лог шринкуется только если его бекапить. Есть плохой способ, гуглить надо backup to null. Нормальные человеки в продакшне его не используют. Есть нормальный, просто бекап на диск или ленточку.
А вообще — зачем вам full? В simple он будет использоваться повторно без бекапов.
нет, бекапится в режиме фул каждый день. + из самой 1С dt'шники выгруджаются.
Я могу перевести в simple режим базу, но проблема увеличивающегося лога все равно остается
Я могу перевести в simple режим базу, но проблема увеличивающегося лога все равно остается
Переведите в simple. Проблема уйдёт.
Журнал транзакций дорастёт до определённого размера (вряд ли он будет превышать 2-3 гб на базе в 20 гб) и устаканится. В simple, при нормальной работе, его размер, примерно будет равен (максимальный объём данных, обрабатываемых в одной транзакции) * 2. Если растёт и не останавливается даже в simple — где-то есть незакрытая транзакция.
Журнал транзакций дорастёт до определённого размера (вряд ли он будет превышать 2-3 гб на базе в 20 гб) и устаканится. В simple, при нормальной работе, его размер, примерно будет равен (максимальный объём данных, обрабатываемых в одной транзакции) * 2. Если растёт и не останавливается даже в simple — где-то есть незакрытая транзакция.
Блин, уже не могу комментарий отредактировать. Не увидел вот это
99%, что 1С-ники по умным рекомендациям 1С настроили на SQL Server job, который проходит по всем индексам в БД и делает ALTER INDEX REBUILD. В этом случае перевод в SIMPLE должен помочь — ЖТ как вырастет на (объём самого большого индекса в бд)*2, так и останется. Вообще, по хорошему, стоит это переделать — на хабре были посты про переиндексацию.
1% остаётся на то, что регламентное задание в 1С что-то шарашит. В принципе, тут тоже перевод в SIMPLE поможет, ЖТ один раз вырастет на нужный ему объём и больше расти не будет.
Рост происходит ночью примерно на объем базы.
99%, что 1С-ники по умным рекомендациям 1С настроили на SQL Server job, который проходит по всем индексам в БД и делает ALTER INDEX REBUILD. В этом случае перевод в SIMPLE должен помочь — ЖТ как вырастет на (объём самого большого индекса в бд)*2, так и останется. Вообще, по хорошему, стоит это переделать — на хабре были посты про переиндексацию.
1% остаётся на то, что регламентное задание в 1С что-то шарашит. В принципе, тут тоже перевод в SIMPLE поможет, ЖТ один раз вырастет на нужный ему объём и больше расти не будет.
Бекап транзакшен лога с обрезкой делаете?
У меня база стоит в Simple. Каждое утро делается бекап с помощью Effector Saver. По поводу log файла вообще не парюсь.
Вы непоняли вмне кажется всетаки суть…
1С это НЕ ТУПО ТРАНСЛЯТОР запросов в SQL,
а ORM и или еще понятнеей 1с — это надстройка над SQL тобиш «Объектная СУБ»… т.е. довольна большая часть работы с данными и бизнес логики — происходит именно в самой 1С а не на стороне SQL/
Соответсвенно затруднять/замедлять конал доступа «Объектной СУБД» к хранилтщу данных НЕЛОГИЧНО.
для примера вам SAP NAVISION — крутися именно на ОДНОМ СУПЕРКОМПЬЮТЕРЕ SGI, а не используются кластеры соединеные сетевыми интерфейсами…
невижу рациональности в этих целях… в применении к ORM ))
небудет скорости в ORM отделенной от Реляционной СУБД сетевыми интерфейсами никогда…
1С это НЕ ТУПО ТРАНСЛЯТОР запросов в SQL,
а ORM и или еще понятнеей 1с — это надстройка над SQL тобиш «Объектная СУБ»… т.е. довольна большая часть работы с данными и бизнес логики — происходит именно в самой 1С а не на стороне SQL/
Соответсвенно затруднять/замедлять конал доступа «Объектной СУБД» к хранилтщу данных НЕЛОГИЧНО.
для примера вам SAP NAVISION — крутися именно на ОДНОМ СУПЕРКОМПЬЮТЕРЕ SGI, а не используются кластеры соединеные сетевыми интерфейсами…
но разносят их по разным компьютером не от хорошей жизни, а с определёнными целями.
невижу рациональности в этих целях… в применении к ORM ))
небудет скорости в ORM отделенной от Реляционной СУБД сетевыми интерфейсами никогда…
хм… улыбнуло))) настраивать сервера для учетной системы по «традициям компании и каким то внутренним требованиям...»...
Пронумерую свои ответы))
1) График — зависимость скорости передачи данных от размера пакета для Ethernet Gigabit
по ВЕРТИКАЛИ скорость предачи данных, по ГОРИЗОНТАЛИ размеры пакетов/
На графике нас интересует «желтая» линия.
2)а про надежность СХЕМЫ — это отдельная тема… в данной я не буду заострять внимание. т.к. тема «Максимально эффективная по скорости работы — серверная схема, для клиент-серверной 1С 8.х»
3) про оптимизацию кода ВНУТРИ 1С для РАЗНЕСЕННЫХ на отдельные физические сервера «Реляционной СУБД» — да это возможно например если вместо «Объектного кода» по макимуму использовать «Реляционный код» (т.е. теже запросы).
но тут главные минусы
— САМОЕ ГЛАВНОЕ саму запись Объектов таки никаким переписывание кода 1с неускорить при разнесенных серверах… как прогрывала на 50% Односервернику так будет.
— как правило получаются как минимум ТЫСЯЧЕ-СТРОЧНЫЕ тексты ЗАПРОСОВ
— естественно требуется довольно квалификацированный специалист… а то некотрые и сервер положат запросом))
— получается доволно сложный в разработке и сложный в последующей поддержке код… скажем так возможно возникновение привязки к конкретному специалисту создавшему сей код.
По поводу логичности или нелогичности разнесения яиц по разным корзинам — давайте не будем делать столь однозначных выводов: у разных компаний разные потребности, требования и традиции
Пронумерую свои ответы))
1) График — зависимость скорости передачи данных от размера пакета для Ethernet Gigabit
по ВЕРТИКАЛИ скорость предачи данных, по ГОРИЗОНТАЛИ размеры пакетов/
На графике нас интересует «желтая» линия.
2)а про надежность СХЕМЫ — это отдельная тема… в данной я не буду заострять внимание. т.к. тема «Максимально эффективная по скорости работы — серверная схема, для клиент-серверной 1С 8.х»
3) про оптимизацию кода ВНУТРИ 1С для РАЗНЕСЕННЫХ на отдельные физические сервера «Реляционной СУБД» — да это возможно например если вместо «Объектного кода» по макимуму использовать «Реляционный код» (т.е. теже запросы).
но тут главные минусы
— САМОЕ ГЛАВНОЕ саму запись Объектов таки никаким переписывание кода 1с неускорить при разнесенных серверах… как прогрывала на 50% Односервернику так будет.
— как правило получаются как минимум ТЫСЯЧЕ-СТРОЧНЫЕ тексты ЗАПРОСОВ
— естественно требуется довольно квалификацированный специалист… а то некотрые и сервер положат запросом))
— получается доволно сложный в разработке и сложный в последующей поддержке код… скажем так возможно возникновение привязки к конкретному специалисту создавшему сей код.
Хочу сказать, что блейды, которые я видел, не собирались в «супер-компьютер», а собирались в кластер нескольких лезвий, объединенных между собой таки сетевыми (пусть и очень быстрыми) интерфейсами — оптические свитчи и т.п. Возможно, я вундервафлю SGI упустил и неправ.
kolu4iy 3 февраля 2015 в 12:43#↵↑
Хочу сказать, что блейды, которые я видел, не собирались в «супер-компьютер», а собирались в кластер нескольких лезвий, объединенных между собой таки сетевыми
да действительно Вы упустили))
1)у SGI — есть «класические блейды»
2) то что я описывал ЭТО НЕ БЛЕЙДЫ и не кластер отдельных компьютеров
а что то из серии например www.sgi.com/products/servers/uv/
линейка продуктов SGI UV 2 позволяет транслировать в единый образ (single system image (SSI)) операционной системы до 2048 ядер (4096 потоков), благодаря инновационному интерконнекту NUMAlink®.
Всё же SSI — это кластер из отдельных хостов, на каждом из которых запущено отдельное ядро операционной системы. Просто эти ядра модифицированы таким образом, что умеют общаются друг с другом по сети, и для userspace притворяются единым пространством процессов, а каждый хост притворяется отдельной NUMA нодой.
Почитайте вот, на хабре тоже было:
habrahabr.ru/post/113387/
Впрочем, с тех пор оно сильно видоизменилось:
www.kerrighed.org/wiki/index.php/UserDoc
Кстати, всё вышесказанное означает, что никакого SSI на винде вы не настроите. Что также подтверждается инфой с сайта SGI:
Так что мечты о запуске 1С на суперкомпьютере — так и останутся мечтами.
Почитайте вот, на хабре тоже было:
habrahabr.ru/post/113387/
Впрочем, с тех пор оно сильно видоизменилось:
www.kerrighed.org/wiki/index.php/UserDoc
Кстати, всё вышесказанное означает, что никакого SSI на винде вы не настроите. Что также подтверждается инфой с сайта SGI:
Building upon 20 years of in-memory computing expertise and utilizing SGI NUMAlink® interconnect technology, these Linux-based servers...
Так что мечты о запуске 1С на суперкомпьютере — так и останутся мечтами.
1)ну во первых можно и на линуксе 1с раскачать))
2)во вторых много способов и Винду поверх Линукса пустить… таже виртулка…
3) в третьих вот погуглил первая ссылка www.sgi.com/company_info/newsroom/press_releases/2010/september/hpc_server.html
что это про 120 ядер под windows 2008 R2?
—
ни вижу ничего такого чтобы сильно мешало этому))
если уж кому нужна система на «базе 1С» Энтерпрайз уровня… то пусть готовять бабки на «правильное железо»… а не на танцы с бубном вокруг ethernet-кластеров и бескононечной программной адаптации и бесконечного ожидания…
*начало иронии* ну вот вот в этой то версии движка кластеры залетают *конец иронии*
2)во вторых много способов и Винду поверх Линукса пустить… таже виртулка…
3) в третьих вот погуглил первая ссылка www.sgi.com/company_info/newsroom/press_releases/2010/september/hpc_server.html
что это про 120 ядер под windows 2008 R2?
—
ekungurov13 февраля 2015 в 20:04#↵↑
…
Так что мечты о запуске 1С на суперкомпьютере — так и останутся мечтами.
ни вижу ничего такого чтобы сильно мешало этому))
если уж кому нужна система на «базе 1С» Энтерпрайз уровня… то пусть готовять бабки на «правильное железо»… а не на танцы с бубном вокруг ethernet-кластеров и бескононечной программной адаптации и бесконечного ожидания…
*начало иронии* ну вот вот в этой то версии движка кластеры залетают *конец иронии*
SAP HANA — вот пример… почему-то именно на таком железе крутится???
Да, админы знают, что это наиболее быстрый способ обмена между 1С и SQL, но разносят их по разным компьютером не от хорошей жизни, а с определёнными целями.
и какие цели приследуют адмны? В чем профит такого разделения?
Да хотя бы в том, что sql server для нормальной работы требует монопольного владения оперативной памятью для кеширования данных, планов исполнения и т.п. Также он не любит разделения доступа к диску, хотя это уже обычно ложится на плечи RAID-контроллера.
Вообще лично я считаю рекомендации 1С по настройке и обслуживанию SQL server вредными, т.к. они во много расходятся с рекомендациями Microsoft. Взять хотя-бы те же реиндексации регулярные, или например maximum degree of parallelism=1.
Вообще лично я считаю рекомендации 1С по настройке и обслуживанию SQL server вредными, т.к. они во много расходятся с рекомендациями Microsoft. Взять хотя-бы те же реиндексации регулярные, или например maximum degree of parallelism=1.
С дисками все ясно…
поделитесь своими проверенными рецептами как готовить 1С и SQL ;)
Вообще лично я считаю рекомендации 1С по настройке и обслуживанию SQL server вредными
поделитесь своими проверенными рецептами как готовить 1С и SQL ;)
Почитать MSDN, если нет денег на курсы по SQL server.
kolu4iy 3 февраля 2015 в 11:43#↵↑
Почитать MSDN, если нет денег на курсы по SQL server.
мне очень нравятся подобные рекомендации… ИБО идите гуглите и будет вам счастие.
Браво! ))
MS Sql server — сложная, серьезная система. Пока вы не понимаете как это устроено внутри, вы не сможете его эффективно использовать. А чтобы начать понимать необходимо заниматься само- или просто обучением. Не гуглить, а читать «от» и «до». Без вариантов.
А чтобы начать понимать необходимо заниматься само- или просто обучением
Это все вы правильно конечно пишете, хочу ответить следующими пунктами))
1) в любой сфере, а в ИТ тем более нужно постоянно и непрерывно заниматся самооброзованием иначе отстанеш от «поезда» ))
2) знать «все на свете невозможно» с учетом всех тонкостей одновременно из каждой области.
3)в ИТ — сфере я бы классифицировал специалистов так (оба класса специалистов необходимы как и их взаимодействие):
-«узкий специалист» — безусловно профи и гуру в своей области, но порой не видит общей картины…
-«универсал» — скажем так «интегратор аналитик»)) имеет зания из многих областей, не такие подробные в каждой как у «узких спецов» — но достаточные для общения с этими спецами в их же области для уточнения ОБЩЕЙ картины)).
По поводу maximum degree of parallelism=1.
Вы очень сильно удивитесь увидев рекомендации от Майкрософта по настройке сиквеля, для Майкрософтовской же Дайнемикс Аксапта)))
На многоядерных системах для высоконагруженного сиквеля сам МС как раз рекомендует maximum degree of parallelism=1
Вы очень сильно удивитесь увидев рекомендации от Майкрософта по настройке сиквеля, для Майкрософтовской же Дайнемикс Аксапта)))
На многоядерных системах для высоконагруженного сиквеля сам МС как раз рекомендует maximum degree of parallelism=1
…
Такое многообещающее начало. За ответ на вопрос из заголовка я даже был готов читать комичную для всех администраторов фразу про «смотрите код в 1С проблемы исключительно там». По моему опыту 1с программисты начинают разговор с того, что проблемы в SQL сервере, а они ведь только по 1С специалисты, так что разберитесь.
Ответ то какой? Какая эффективная платформа?
А оказывается все просто. Вариант 1 — 1с не масштабируется, вариант 2 — совсем не масштабируется.
Просто дайте ей один большой быстрый процессор и не разносите бд и сервер приложений на разные физические серверы, такой вывод?
Ответ то какой? Какая эффективная платформа?
А оказывается все просто. Вариант 1 — 1с не масштабируется, вариант 2 — совсем не масштабируется.
Просто дайте ей один большой быстрый процессор и не разносите бд и сервер приложений на разные физические серверы, такой вывод?
вариант 2 — совсем не масштабируется.
не понятна эта фраза,
1) у меня вариант 2 как раз масштабируется путем добавления новых «лезвий» в «Большой компьютер»))
2) касательно "… начинают разговор с того, что проблемы в SQL сервере, а они ведь только по 1С специалисты.." Цитатой отвечу
1С это НЕ ТУПО ТРАНСЛЯТОР запросов в SQL,
а ORM и или еще понятнеей 1с — это надстройка над SQL тобиш «Объектная СУБ»… т.е. довольна большая часть работы с данными и бизнес логики — происходит именно в самой 1С а не на стороне SQL/
Суть в том что надо расматривать ВСЮ ситему В ЦЕЛОМ а не отдельно SQL и отдельно 1С.
еще хочу уточнить для вас
допустим ORM платформа работает с «неким объектом» полученным из БД…
не забывайте что он при получении в ORM НЕ СТАНОВИТСЯ так сказать «отрезанным» от базы данных, а как раз ситема непрерывно поддерживает его синхронизацию с БД…
допустим ORM платформа работает с «неким объектом» полученным из БД…
не забывайте что он при получении в ORM НЕ СТАНОВИТСЯ так сказать «отрезанным» от базы данных, а как раз ситема непрерывно поддерживает его синхронизацию с БД…
Может быть в этом и проблема? Видел отчеты выполняющиеся по несколько часов. Как в этом случае может быть виноват канал? За это время базу целиком можно раз 20 скопировать.
Мой комментарий как и ваша статья не дает ничего нового в вопросе обслуживания 1с.
1с очень странно работает с скл. Время выполнения и оптимизация как правило не имеют линейной связи с призводительностью системы. Больше всего пользы от логической оптимизации, а именно от 1с программиста который думает о производительности.
Мой комментарий как и ваша статья не дает ничего нового в вопросе обслуживания 1с.
1с очень странно работает с скл. Время выполнения и оптимизация как правило не имеют линейной связи с призводительностью системы. Больше всего пользы от логической оптимизации, а именно от 1с программиста который думает о производительности.
да действительно
Поэтому как правило очеты стараются реализовать одним объектом 1С «Запрос» + стараются чтобы в результате выполненого запроса было поменьше данных «Объектного типа» — т.е. фактически приведение к примитивным типам «Строка» и т.д.
если в коде модуля «Очета» используется множественные переменные «Обектного типа» — то да ожидания окончания блокировок в таблицах связанных с этими объектами вполне реально и может занимать значительную часть времени от формирования Отчета.
Поэтому как правило очеты стараются реализовать одним объектом 1С «Запрос» + стараются чтобы в результате выполненого запроса было поменьше данных «Объектного типа» — т.е. фактически приведение к примитивным типам «Строка» и т.д.
А другие программисты об этом знают?
anton1234 3 февраля 2015 в 21:31#↵↑
А другие программисты об этом знают?
в комментария темы
был пример про немного более квалифицированных программистов 1С, которые разогнали обработку с 9 часов до одного, т.е. почти порядково увеличили производительность системы.
так что получается НЕКОТОРЫЕ программисты знают))
Просто дайте ей один большой быстрый процессор и не разносите бд и сервер приложений на разные физические серверы, такой вывод?
суть верна))
но так как в одной микросхеме никак не уместить очень много БЫСТРЫХ ядер… из--за тех же проблем с тепловыделением — поэтому и описал в теме пример про много-сокетные «большие компьютеры» SGI.
Ничего не понятно.
Связь между 1С и SQL по сети идёт через TCP, у которого есть такое понятие как «размер окна», которое обычно в начале коннекта мало, но потом увеличивается плавно или еще как-то, в зависимости от алгоритма TCP Congestion Control (в том же линуксе их десяток).
Размер окна означает количество данных, переданных без подтверждения (АСК) и особый смысл имеет на высоколатентных каналах, где пока дождёшься этого АСКа — пройдёт целая вечность. В локалке 1 или 10Гбит с латентностью меньше миллисекунды оно уже не так важно.
Если бы 1С каждый раз бы устанавливало соединение с базой и потом его рвало, то окно постоянно сбивалось бы на небольшое.
Но, я думаю, что коннект с СУБД 1С всё же держит открытым и окно там успевает увеличиться до каких-то адекватных значений.
Плюс, изначальный размер окна, насколько я помню, в тех же линуксах можно настраивать, в винде наверное тоже есть такая возможность.
Да, наблюдал как раз в связке 1С и MSSQL интересный баг (или фичу?): они находились на разных виртуалках, между хостами сеть 10Гбит, джумбо фреймы до 9000. Скорость по iperf между виртуалками плавала где-то между 2 и 4Гбит.
При включении на виртуальных адаптерах vmxnet3 джумбо фреймов скорость увеличивалась до 9Гбит, но 1С начинал просто адски тупить. Причину так установить не смогли и забили, вернув MTU на 1500.
Связь между 1С и SQL по сети идёт через TCP, у которого есть такое понятие как «размер окна», которое обычно в начале коннекта мало, но потом увеличивается плавно или еще как-то, в зависимости от алгоритма TCP Congestion Control (в том же линуксе их десяток).
Размер окна означает количество данных, переданных без подтверждения (АСК) и особый смысл имеет на высоколатентных каналах, где пока дождёшься этого АСКа — пройдёт целая вечность. В локалке 1 или 10Гбит с латентностью меньше миллисекунды оно уже не так важно.
Если бы 1С каждый раз бы устанавливало соединение с базой и потом его рвало, то окно постоянно сбивалось бы на небольшое.
Но, я думаю, что коннект с СУБД 1С всё же держит открытым и окно там успевает увеличиться до каких-то адекватных значений.
Плюс, изначальный размер окна, насколько я помню, в тех же линуксах можно настраивать, в винде наверное тоже есть такая возможность.
Да, наблюдал как раз в связке 1С и MSSQL интересный баг (или фичу?): они находились на разных виртуалках, между хостами сеть 10Гбит, джумбо фреймы до 9000. Скорость по iperf между виртуалками плавала где-то между 2 и 4Гбит.
При включении на виртуальных адаптерах vmxnet3 джумбо фреймов скорость увеличивалась до 9Гбит, но 1С начинал просто адски тупить. Причину так установить не смогли и забили, вернув MTU на 1500.
уточнили в предыдущем сообщении, спс kolu4iy
4кб — размер пакета SQL сервера.
Если в сети не включены jumbo frames, то на tcp уровне он уже побьется на 1472 байта, и фрагментами дойдет до получателя.
График, насколько я понимаю, как раз для размера TCP пакета и не имеет отношения к размеру пакета SQL server.
Попингуйте соседа из командной строки
ping -l 1472 -f 172.30.100.219
ping -l 1476 -f 172.30.100.219
ping -l 4000 -f 172.30.100.219
и сами все увидите. -f запрещает фрагментацию пакета, и вы тем самым найдете максимальный размер пакета на уровне icmp (MTU — icmp header). На TCP он будет отличаться на пару байт.
Тем не менее накладные расходы возникают как на сетевом уровне (заголовки TCP), так и на прикладном (SQL-пакет). SQL пакет фрагментируется в более мелкие, и они действительно добавляют проблем.
Скорость по iperf между виртуалками плавала где-то между 2 и 4Гбит.
размер пакета какой в утилите iperf указывали? рекомендую на вашей 10Гбит проверить скорость передачи указав в клиентской части утилиты размер пакета 4 кб. Будет видно серьезное сужение канала передачи))
В TCP нет понятия размера пакета, он ограничивается MTU. Там есть окно. Учите матчасть.
Пордон наверное некоректно написал «размер пакета TCP»
В настройках MS SQL сервера Network Packet Size = 4096 байт
в утилите iperef использовали ключ "-l length" — это изменение ДЛИНЫ пакета. что при = 4 кб дало такую же загрузку сети как мы видили при общении «Сервер 1С»<-Ethenet->«MS SQL»
Ваши рекомендации как правильнее описать данную ситуацию?
В настройках MS SQL сервера Network Packet Size = 4096 байт
в утилите iperef использовали ключ "-l length" — это изменение ДЛИНЫ пакета. что при = 4 кб дало такую же загрузку сети как мы видили при общении «Сервер 1С»<-Ethenet->«MS SQL»
Ваши рекомендации как правильнее описать данную ситуацию?
когда-то на форумах 1С видел парочку success story о том что параметр maxdop для MS SQL делает чудеса. Что вы думаете об этом?
maxdop — параметр запроса. Означает максимально возможную степень распараллеливания выполнения того самого запроса. Имеет смысл только при малом количестве ядер, либо при неравномерной и непредсказуемой их загрузке. В описанном случае расходы на распараллеливание а, самое главное, на ожидание синхронизации потоков после завершения, превышают профит от их параллельного выполнения. Очень хорошо под описанное подходит тот самый случай сосуществования 1С и SQL server на одном железе.
У меня сейчас система (не 1С) стоит на 20-ядернике. Кроме того, в тот же сервер едет еще одна ERP. Если я поставлю maxdop=1 то всё просто умрёт.
У меня сейчас система (не 1С) стоит на 20-ядернике. Кроме того, в тот же сервер едет еще одна ERP. Если я поставлю maxdop=1 то всё просто умрёт.
Всё зависит от приложения.
1С долго рекомендовала его менять при проблемах с блокировками и наконец добавила MAXDOP=1 в стандартное руководство. А SharePoint даже не установится при значении отличном от единицы.
1С долго рекомендовала его менять при проблемах с блокировками и наконец добавила MAXDOP=1 в стандартное руководство. А SharePoint даже не установится при значении отличном от единицы.
Опция Maximum Degree of Parallelism (DOP) определяет число потоков, на которые SQL Server может распараллелить запрос и фактически означает число используемых для этого ядер CPU.
чудес особых невидел окромя повышенной загрузки ядер CPU, у нас устоновлено=1.
пс:
Тюнинг «Реляционной СУБД» конечно вещь полезная, но я бы не упирал на то что «ускорение работы Реляционной СУБД» однозначно ускорит работу «Объектной СУБД(1С)»… есть ряд ньюансов так сказать))
… например туже проблему Ehernet я описал))
чудес особых невидел окромя повышенной загрузки ядер CPU, у нас устоновлено=1.
пс:
Тюнинг «Реляционной СУБД» конечно вещь полезная, но я бы не упирал на то что «ускорение работы Реляционной СУБД» однозначно ускорит работу «Объектной СУБД(1С)»… есть ряд ньюансов так сказать))
… например туже проблему Ehernet я описал))
По-моему это не статья, а жалкая попытка убедить всех что 1С не говно.
Один сервер, два, обычные диски, твердотельные — это все поровну. Как выполнялся отчет за 3 часа так и будет. И ни от каких размеров чего угодно это не зависит.
Один сервер, два, обычные диски, твердотельные — это все поровну. Как выполнялся отчет за 3 часа так и будет. И ни от каких размеров чего угодно это не зависит.
Да вы что то путаете… и уходите от данной темы.
1) я не кого не убеждал что 1С не говно ))
я описал как можно ускорить работу «платформы 1С» построив подходящую для нее серверную схему.
2) Как выполнялся отчет за 3 часа так и будет. И ни от каких размеров чего угодно это не зависит.
не обоснованное утверждение,
для примера приведу результат времени проведения некого тяжелого документа из практики.
а) «Двух-серверная модель» — 1ч 8 минут.
б) «Односерверная модель» — 30 минут.
1) я не кого не убеждал что 1С не говно ))
я описал как можно ускорить работу «платформы 1С» построив подходящую для нее серверную схему.
2) Как выполнялся отчет за 3 часа так и будет. И ни от каких размеров чего угодно это не зависит.
не обоснованное утверждение,
для примера приведу результат времени проведения некого тяжелого документа из практики.
а) «Двух-серверная модель» — 1ч 8 минут.
б) «Односерверная модель» — 30 минут.
Если один отчет создаёт миллионы микротранзакций, то это плохой, негодный отчет. Возможно, плоха и негодна архитектура системы, а не сам отчёт. Возможно программист — выше был пример про немного более квалифицированных программистов 1С, которые разогнали обработку с 9 часов до одного, т.е. почти порядково увеличили производительность системы.
Если система не загружает на 100% ни hdd, ни cpu, ни ram, ни что-то другое и при этом не увеличивает свою производительность, то это плохая, негодная система. То, что можно немного поджать тут, зажать там по факту борется со следствиями, а не с причиной.
kolu4iy 3 февраля 2015 в 12:38#↵↑
Если один отчет создаёт миллионы микротранзакций, то это плохой, негодный отчет. Возможно, плоха и негодна архитектура системы, а не сам отчёт.
пордон вы про «Отчет» который просто выводит данные?
Насколько я в курсе блокировки могут возникнуть в этом случае только при указании специальных инструкций «блокировки» в тексте объекта 1с «Запрос» или в самом коде модуля очета.
Обычно в отчете происходит «грязное» чтение…
+ к предыдущему
…
хотя если в коде модуля «Очета» используется множественные переменные «Обектного типа» — то да ожидания окончания блокировок в таблицах связанных с этими объектами вполне реально и может занимать значительную часть времени от формирования Отчета. Тогда да согласен с Вами «Отчет негодный»))
…
хотя если в коде модуля «Очета» используется множественные переменные «Обектного типа» — то да ожидания окончания блокировок в таблицах связанных с этими объектами вполне реально и может занимать значительную часть времени от формирования Отчета. Тогда да согласен с Вами «Отчет негодный»))
Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.
Конечно, у файлового режима скорость передачи данных между СУБД и объектной моделью будет выше. Но это совершенно не означает, что скорость работы платформы будет выше. Системы уровня SQL применяют умные алгоритмы и оптимизации, вряд ли файловая СУБД 1С умеет так же.
movsb 4 февраля 2015 в 08:54#
Системы уровня SQL применяют умные алгоритмы и оптимизации, вряд ли файловая СУБД 1С умеет так же.
Это все имеет место быть, но выигрыш систем SQL будет виден только на больших базах данных и при одновременной работе большого количества пользователей.
Файловая же версия — ограничена в использовании небольшим объемом базы(ограничение используемого движка «Реляционной СУБД») и небольшим количеством одновременно работающих пользователей( из-за блокировок в транзакции вместо исключительно изменяемых данных — блокируюся таблицы целиком имеющие связи с записываемым объектом).
В файловом режиме вполне достаточно «не такого хирого алгоритма» использующего индексные таблицы.
Т.е по скорости работы платформы 1С при прочих равных условиях и при условии «монопольного однопользовательского» сеанса: однозначно выграет файловый вариант.
Небольшое исследование показало, что Вы правы. В файловой базе документы проводятся на 20% быстрее. Долгие отчеты формируются в 3-5 раз быстрее в файловой базе, хотя надежда победы SQL-версии была именно на них.
добавлю в тему — существует еще более производительная технология "хранения объектных данных" — это «разряженные массивы» — где посути используются многомерные массивы для хранения объекта целиком вместо размазывания объекта по многим таблицам и перемешивания данных в них из разных объектов.
пример реализации intersystems.ru/cache/technology/techguide/cache_tech-guide_02.html
(сразу оговорюсь данную технологию «руками» на практике пока недовелось потрогать)))
но думаю проект mail.ru не зря запатентовал одну из реализаций для «высоко нагруженных проектов» )
пример реализации intersystems.ru/cache/technology/techguide/cache_tech-guide_02.html
(сразу оговорюсь данную технологию «руками» на практике пока недовелось потрогать)))
но думаю проект mail.ru не зря запатентовал одну из реализаций для «высоко нагруженных проектов» )
Долгие отчеты формируются в 3-5 раз быстрее в файловой базе, хотя надежда победы SQL-версии была именно на них.
Т.к. в отчетах как правило используется объект 1С «Запрос» или его реализация в СКД и т.п — и многих людей сбивает с толку SQL-подобность текста этого «запроса».
Тут ситуация в следующем(я уже описывал) — это не напрямую транслируемый один в один в «SQL-код запрос»,
а прежде всего «Объектный запрос» — отсюда вытекают затраты на сборку объектов и их оработку перед выдачей результатов.
Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».
IT-шники абсолютно правы. Только надо не код 1С смотреть, а проводить замеры производительности.
Первое что надо сделать, это понять, проблема ли это производительности или параллельности: Базовый способ проверки — запустить систему в нагруженном состоянии и провести замер ключевой операции, а затем в не нагруженном — и сравнить.
Если показатели будут одинаковы — то это проблема производительностиэ Тут два варианта — Плохая работа запроса или плохая работа кода. В первом случае запукается профайлер SQL и смотрится план выполнения запроса, оптимизируется, во втором случае запускается замер производительости, ищется пиковая операция — оптимизируется.
Если показатели различны — это проблема параллельности. Надо искать бутылочное горлышко.
Вариантов несколько — Несправляется оборудование (но мы уже отметили, что все хорошо), Избыточная блокировка в 1С или в СУБД, либо это неподконтрольная ситуация (например используется аппаратный хасп ключ, который работает в одном потоке, и одновременно к нему по сети рвутся 1000 юзеров — тут надо ставить программный ключ).
Что касается блокировок — то тут тоже все более чем расписано:
1. поиск избыточных блокировок (например установлен автоматический режим, для высоконагруженных систем надо использовать управляемый и ручками прописывать что и когда должно блокироваться в транзацкии)
2. поиск взаимоблокировок (1с-ка умная, она сама разрывает взаимоблокировки, но пока она поймет, что это взаимоблокировка — пройдет время, что сказывается на производительности)
3. поиск эскалации блокировок (при попытке заблокировать очень большой кусок строк таблицы 1с-ка понимает, что хранить данные по такой таблице дороже, чем заблокировать таблицу целиком, потому все вынуждены ждать пока таблица полностью освободится — не стоит проводить документы с тысячами строк, так же такая пробелма возникает, когда в таблице всего одна запись, напрмиер если вы будете вести учет только в разрезе одной номенклатуры, то у вас все будет жутко тормозить, просто потому что все разрезы всех регистров будут заблокированы в транзакции)
Так же стоит отметить, что проблема параллельности и узких горлышек — это самая противная пробелема. Если в высоконагруженной системе загрузка оборудования минимальна — это значит лишь то, что есть проблема очереди до момента загрузки оборудования. И решив одну проблему — узкое горлышко может появиться в другом. Цепочка может быть очень долгой. Как, например, решив проблемы в магазине на очереди к весам, при том что очередей к касам нет, мы получим, что люди быстрее взвшивают и быстрее идут к касам, и образуют там очередь, решив пробелму на кассе, мы получим пробелму на выходе из магазина — все одновременно рвутся к выходу и не дают друг другу пройти…
Так же стоит отметить, что проблема параллельности и узких горлышек — это самая противная пробелема. Если в высоконагруженной системе загрузка оборудования минимальна — это значит лишь то, что есть проблема очереди до момента загрузки оборудования.
согласен убираеш одно узкое место вылазит другое — поэтому я и пишу что ненадо концентрироватся на какой-то одной части системы…
НЕОБХОДИМО смотреть на ВСЮ СИСТЕМУ В ЦЕЛОМ.
Пэтому вашу концентрацию исключительно на SQL считаю в КОРНЕ НЕВЕРНЫМ подходом.
Видимо я недостаточно описал что такое ORM? В публикации я вроде был дал яно понять, что в данной системе работают две базы «Реляционная» и виртуальная «Объектная» и соответсвенно их обслуживают разные виды СУБД.
поиск эскалации блокировок (при попытке заблокировать очень большой кусок строк таблицы 1с-ка понимает, что хранить данные по такой таблице дороже, чем заблокировать таблицу целиком
тут скорее НЕСОГЛАСЕН… насколько я вкурсе… решение УКРУПНИТЬ БЛОКИРОВКУ и заблокировать ВСЮ ТАБЛИЦУ или ДАЖЕ ИХ ГРУППУ принимает SQL а не 1С.
Хотя в 1С есть определенные виды «объектных» блокировок, которые контролирует именно 1С на уровне «Объектной базы»…
НЕОБХОДИМО смотреть на ВСЮ СИСТЕМУ В ЦЕЛОМнет же, надо не смотреть на систему, а замеры проводить, и решения относительно фактических данных принимать.
Собственно все, что я описал, и более подробно о методике оптимизации, как кода, блокировок, запросов, SQL, настройке оборудования и сети написано в книжке Настольная книга 1С: Эксперта по технологическим вопросам.
И еще более подробно показывается в тренинге при аттестации на 1С: Эксперт по технологическим вопросам.
хорошо раз цепляетесь к словам))
не смотреть и медитировать а «РАСМАТРИВАТЬ» систему в целом,
УТОЧНЯЮ ЧТО Я КОНКРЕТНО ИМЕЛ ВВИДУ: это то, что в данном случае означает не тестирование SQL отдельно без платформы 1С (выполняя бесмысленные в данной ситуации тесты оснаванные на генерации «прямых SQL запросов» без участия платформы 1С),
я же предлагаю тестировать производительность самой платформы 1С в конкретных условиях… например один из тестов «Стандартный нагрузочный тест 1С» и тут уже можно смотреть как нагрузку на сеть, так и что творится на SQL и т.д.
а еще лучше дополнителное СЦЕНАРНОЕ тестирование на КОНКРЕТНОЙ конфигурации…
ТЕПЕРЬ понятно Вам изложил?
не смотреть и медитировать а «РАСМАТРИВАТЬ» систему в целом,
УТОЧНЯЮ ЧТО Я КОНКРЕТНО ИМЕЛ ВВИДУ: это то, что в данном случае означает не тестирование SQL отдельно без платформы 1С (выполняя бесмысленные в данной ситуации тесты оснаванные на генерации «прямых SQL запросов» без участия платформы 1С),
я же предлагаю тестировать производительность самой платформы 1С в конкретных условиях… например один из тестов «Стандартный нагрузочный тест 1С» и тут уже можно смотреть как нагрузку на сеть, так и что творится на SQL и т.д.
а еще лучше дополнителное СЦЕНАРНОЕ тестирование на КОНКРЕТНОЙ конфигурации…
ТЕПЕРЬ понятно Вам изложил?
Тестировать надо не платформу — платформа, это лишь средство запуска программы, исполняемая среда, тестировать надо конфигурацию.
Тестировать SQL впринципе надо только в случае проблемы с производительностью, т.е. блокировки тут вообще не причем. Конкретно, надо смотреть как 1С свой запрос переводит в запрос SQL. Делается это с помошью профайлера SQL, который показывает каой план выполнения запроса построила SQL. Даже без участия 1С SQL перед выполнением запроса пытается построить план, который позволит исполнить запрос быстрее. Конкретно чаще всего долгое выполненеи запроса происходит из-за того, что SQL выбрало неоптимально: оператор сканирования (Clustered Index Scan, Index Scan, Table scan), оператор поиска по индексу (Clustered Index Seek, Index Seek) или оператор соединения (Nested Loops, Marge Join). При этом если есть один из этих плохих операторов, то по этим симптомам можно сразу привести соответствие кода 1С, которое могло вызвать его появление. Конкретно рекомендации к составлению запросов 1С и составляют так, чтобы при трансляции в SQL этих операторов не появилось.
Что касается бокировок, я говорю исключительно о блокировках в транзакциях 1С. При этом есть подробное соответствие какая блокировка 1с для управляемого или автоматического режима вызовет какую блокировку SQL для каждого из объектных и необъектных типов 1С.
Потому естественно надо производить замеры на системе в целом, а после уже по симптомам переходить к замерам отдельных составляющих.
Тестировать SQL впринципе надо только в случае проблемы с производительностью, т.е. блокировки тут вообще не причем. Конкретно, надо смотреть как 1С свой запрос переводит в запрос SQL. Делается это с помошью профайлера SQL, который показывает каой план выполнения запроса построила SQL. Даже без участия 1С SQL перед выполнением запроса пытается построить план, который позволит исполнить запрос быстрее. Конкретно чаще всего долгое выполненеи запроса происходит из-за того, что SQL выбрало неоптимально: оператор сканирования (Clustered Index Scan, Index Scan, Table scan), оператор поиска по индексу (Clustered Index Seek, Index Seek) или оператор соединения (Nested Loops, Marge Join). При этом если есть один из этих плохих операторов, то по этим симптомам можно сразу привести соответствие кода 1С, которое могло вызвать его появление. Конкретно рекомендации к составлению запросов 1С и составляют так, чтобы при трансляции в SQL этих операторов не появилось.
Что касается бокировок, я говорю исключительно о блокировках в транзакциях 1С. При этом есть подробное соответствие какая блокировка 1с для управляемого или автоматического режима вызовет какую блокировку SQL для каждого из объектных и необъектных типов 1С.
Потому естественно надо производить замеры на системе в целом, а после уже по симптомам переходить к замерам отдельных составляющих.
ZEEGIN 5 февраля 2015 в 09:29#↵↑
Собственно все, что я описал, и более подробно о методике оптимизации, как кода, блокировок, запросов, SQL, настройке оборудования и сети написано в книжке Настольная книга 1С: Эксперта по технологическим вопросам.
хотя что я разряюсь)))
все же можно решить почитав ЖКК (желто красные книжки) — там есть все ответы на все случаи жизни…
удачи вам,
далее ваши посты буду игнорировать похоже… пока я эти ЖКК не изучу под МИКРОСКОПОМ видимо там спрятаны ответы… ))).
кстати вот одна из рецензий на предложенную вами книгу
ЦИТАТА
Не нужно думать, что в книге вы получите исчерпывающие ответы на все вопросы по производительности, вовсе нет. Скорее она может направить в правильную сторону, и дать инструкции как поиску ответов самостоятельно. Книга не сделает из вас эксперта, так же как руководство по управлению самолетом, не сделает из вас пилота. Для этого нужен опыт, опыт и еще раз опыт.
Как то странно на хабре построенна система комментариев на мой взгляд))
Пишеш ответ на предыдущий пост, а в это же время автор предыдущего его меняет…
блин все как в 1С «проблема реадктирования задним числом» )))
а так как предыдущий пост может кардинально поменятся по смысло, то твой ответ начинает выглядеть как «ответ на вопрос из КОСМОСА» ))
Пишеш ответ на предыдущий пост, а в это же время автор предыдущего его меняет…
блин все как в 1С «проблема реадктирования задним числом» )))
а так как предыдущий пост может кардинально поменятся по смысло, то твой ответ начинает выглядеть как «ответ на вопрос из КОСМОСА» ))
ZEEGIN в личке перетерли… я надеюсь больше не будет мыслей о моей компетенции? ))
я конечно не бородатый БЭПЕР но… кхм… немалый опыт имеемс… а его как говорится не пропьеш))
— ой что то я отошел от своего принципа всегда писать только по теме.
— Далее прошу если у кого есть вопросы не по этой конкретной теме пишите в личку.
зачем засорять топик.
я конечно не бородатый БЭПЕР но… кхм… немалый опыт имеемс… а его как говорится не пропьеш))
— ой что то я отошел от своего принципа всегда писать только по теме.
— Далее прошу если у кого есть вопросы не по этой конкретной теме пишите в личку.
зачем засорять топик.
«20% загрузки сетевого интерфейса» = «20% полезные данные» + «80% потеря на служебной обработке»
эээ, что?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Максимально эффективная по скорости работы — серверная схема, для клиент-серверной 1С 8.х