Оптимизация по-русски. Оптимизация по
Оптимизация ПО
Компания «Райс» предлагает услуги по оптимизации программного обеспечения (ПО).
Оптимизация ПО – это тонкая настройка и модификация системы для улучшения ее эффективности или, другими словами, улучшение производительности системы.
Оптимизация ПО – зачем это нужно?
Темп бизнес-процессов любой компании зависит от оптимизации самих процессов, их логики, исполнительской дисциплины, в том числе, и от качества работы программного обеспечения.
Производительность системы зависит от увеличения объема хранения данных, роста числа пользователей, выявления неоптимальных запросов или методических ошибок при проектировании. Самая частая проблема – это блокировки данных, возникающие в многопользовательских системах управления базами данных (СУБД).
Для того чтобы система развивалась вместе с предприятием, гибко подстраивалась под его рост, требуется оптимизация программного обеспечения.
Оказываемые услуги
Специалисты компании «Райс» предлагают следующие работы по оптимизации программного обеспечения.
Диагностика:
- выявление «узких» мест в оборудовании;
- оценка интегральной производительности ключевых операций;
- поиск длительных ожиданий на блокировках и взаимоблокировках.
Оптимизация:
- исправление ошибок, приводящих к взаимоблокировкам;
- оптимизация запросов и программного кода;
- настройка индексов;
- настройка сервера СУБД;
- уменьшение времени ожидания;
- рекомендации по модернизации оборудования.
Главным показателем оптимизации является предотвращение потери данных, которые возникают при обнаружении ошибок. Пользователи получают возможность работать параллельно, увеличивается масштабируемость и производительность системы в целом, а время простоя снижается.
Дополнительную информацию об услуге «Оптимизация программного обеспечения» можно получить по телефону +7(495)666-22-38 или по электронной почте [email protected]
msk.risecompany.ru
сложно, но порой необходимо / Блог компании JUG.ru Group / Хабр
— Расскажите о себе и своей работе. Какую роль в вашей работе играют оптимизации по памяти?
Андрей Акиньшин: Меня зовут Андрей Акиньшин, и я работаю в компании JetBrains, где много времени уделяю оптимизации приложений. Среди прочего мы занимаемся разработкой кроссплатформенной .NET IDE под названием Rider, основанной на платформе IntelliJ и ReSharper. Это очень большой продукт, который много чего умеет. Естественно, он должен быть хорошо оптимизирован с точки зрения работы с памятью. Нужно сделать так, чтобы работа с памятью не тормозила продукт, а расход этой памяти был как можно меньше. Для подобной оптимизационной работы надо хорошо понимать, как эта самая память устроена и какие проблемы с ней могут возникнуть.
В свободное время я также разрабатываю проект с открытым исходным кодом BenchmarkDotNet. На текущий момент он уже достаточно большой, разработка проходит при поддержке .NET Foundation. Эта библиотека помогает людям писать бенчмарки, замеряющие производительность тех или иных вещей.
Вообще, когда речь идет о памяти, аккуратно замерить производительность достаточно сложно. Приходится понимать и учитывать очень много факторов, которые могут повлиять на перформанс. Поэтому зачастую мало провести какой-то один эксперимент (бенчмарк), чтобы сделать выводы о производительности памяти в целом. Также важно понимать, что для разных процессорных архитектур и JIT-компиляторов приходится проводить отдельные исследования по производительности. BenchmarkDotNet упрощает эту работу.
— На ваш взгляд, на каком месте в процессе оптимизации вообще должна стоять работа с памятью? Или все индивидуально и зависит от деталей приложения?
Андрей Акиньшин: Конечно же, многое зависит от приложения. Очень важно понимать узкое место в производительности конкретно вашей программы. Например, если вы много работаете с базами данных, вполне вероятно, что узкое место — это база данных, т.е. в первую очередь нужно думать о ней. А может быть, вы 99% времени тратите на сетевые операции. Всегда необходимо понимать, из чего в принципе складывается ваша производительность.
Тем не менее, в очень большом количестве разных проектов часто возникают ситуации, когда мы выполняем какие-то операции не над базой данных, не над сетью или дисками, а именно над основной памятью компьютера. И нам хотелось бы, чтобы эти места работали как можно быстрее.
Но если вам кажется, что какой-то компонент работает медленно, не нужно сразу кидаться оптимизировать память, да и вообще что угодно. Во-первых, стоит с самого начала осознать, что у вас есть некая проблема, из-за которой ухудшается производительность приложения. Во-вторых, надо сформулировать, насколько она вас не устраивает и насколько вам нужно разогнать приложение, потому что оптимизация ради оптимизации — это не то, чем стоит заниматься. Важно хорошо понимать бизнес-цели, которые стоят за этой работой. И только когда мы определились с целями, когда мы понимаем, какие у нас есть объективные метрики, которые мы хотим улучшить (насколько мы их хотим разогнать) — тогда уже стоит смотреть, во что по скорости упирается программа. И если это память — необходимо оптимизировать память. Если это что-то другое — нужно работать в другом направлении.
— Почему бенчмаркинг памяти такой сложный?
Андрей Акиньшин: Дело в том, что если мы два раза померяем время работы одной и той же программы, мы получим два разных результата. Выполнив очень много замеров, мы получим какое-то распределение с определенной дисперсией. И в случае работы с основной памятью эта дисперсия оказывается достаточно большой. Чтобы улучшить программу с точки зрения производительности по доступу к памяти, нужно очень хорошо понимать, как выглядит это распределение и что может независимо от нашей непосредственной логики влиять на итоговую скорость работы программы.
На скорость доступа к памяти влияет очень много факторов (о которых мы зачастую не задумываемся), мы можем сделать замеры у себя на машине в одних условиях, выполнить какие-то оптимизации, а на пользовательском компьютере профиль работы будет совсем другой, так как там другое железо. — В своем докладе на DotNext вы собираетесь рассказывать о большом количестве низкоуровневых вещей. Действительно ли .NET-программистам нужно понимать нюансы устройства CPU для оптимизационных работ?
Андрей Акиньшин: В большинстве случаев — нет. Основные перфоманс-проблемы — не особо интеллектуальные, их можно решать, используя общие знания. Но когда простые проблемы решены, производительность все еще упирается в память, а скорость работы надо как-то увеличивать, низкоуровневые знания лишними не будут.
Начну я со знакомой многим вещи — с кэша процессора. Очень важно писать алгоритмы, которые достаточно дружественны к кэшу. Это не так сложно и не требует каких-то больших знаний, а по скорости можно выгадать очень много. К сожалению, многие профайлеры не позволяют просто так получить количество промахов кэша (cache miss). Но есть специализированные инструменты, позволяющие смотреть именно хардварную информацию. Я использую Intel VTune Amplifier, это очень хороший инструмент — он показывает проблемы не только с кэшем, но и с другими вещами, например, с выравниванием (если у вас много доступа к невыровненным данным, из-за этого может проседать производительность).
Есть такие штуки, о которых многие не знают или не задумываются, — например store forwarding или 4K aliasing: они могут легко испортить наши бенчмарки и привести к некорректным выводам. Мы можем получить проседание по скорости, просто обратившись одновременно по двум адресам, расстояние между которыми оказалось «неудачным». Оптимизация по этим вещам вряд ли даст вам какой-то гигантский прирост по перформансу, но зато может помочь там, где уже ничего другое не поможет. А непонимание внутренней кухни может легко привести к написанию некорректных бенчмарков. Поэтому полезно уметь смотреть и анализировать хардварные счетчики и делать выводы о том, в какую сторону стоит продолжать оптимизационные работы. — Сейчас очень многие говорят о разработке кроссплатформенных .NET-приложений. Есть ли какие-нибудь различия между работой с памятью под разными рантаймами и операционными системами?
Андрей Акиньшин: Разумеется. Главным образом, это высокоуровневые проблемы, связанные со сборкой мусора. Например, алгоритмы сборки мусора под Mono и полным фреймворком совершенно разные. Идет разная работа с поколениями, по-разному обрабатываются большие объекты.
Кстати говоря, большие объекты — это довольно распространенная проблема. В полном фреймворке у нас есть куча больших объектов (Large Object Heap, LOH), в которую попадают объекты, размер которых превышает 85000 байт. И если обычную кучу сборщик мусора постоянно проверяет, вычищает и дефрагментирует, то над кучей больших объектов операция дефрагментации проводится достаточно редко (по умолчанию она вообще не проводится, но в последних версиях фреймворка ее можно вызвать вручную, если вы считаете, что такая необходимость есть). Поэтому с этой кучей нужно работать очень аккуратно: следить, чтобы у нас больших объектов по возможности не появлялось.
А под Mono у нас уже имеется не 3 поколения, а 2; концепт больших объектов там тоже есть, но работа с ним ведется совершенно иначе. И наши старые эвристики, которые мы применяли для больших объектов под Windows, на Linux под Mono работать не будут.
— Расскажите, пожалуйста, о какой-нибудь проблеме из продакшн?
Андрей Акиньшин: В Rider-е есть много проблем с той же кучей больших объектов. Если мы создаем очень большой массив (который попадает в LOH) на не очень большой промежуток времени, это не очень хорошо, т.к. увеличивает фрагментированность LOH. Классическим решением в этой ситуации является создание вспомогательного класса — так называемого чанк-листа (chunk list): вместо выделения большого массива мы создаем несколько маленьких (чанков), каждый из которых достаточно мал, чтобы не попасть в LOH. Снаружи мы оборачиваем их в красивый интерфейс, чтобы для пользователя они выглядели как единый список. Это спасает нас от большого LOH и дает приятный выигрыш по расходу памяти.
Подобное решение у нас в ReSharper используется достаточно давно. Однако сейчас, когда мы пишем Rider (т.е. по сути запускаем ReSharper на Mono под Linux), этот хак не работает по задумке: как я уже говорил, в Mono логика работы с хипом совершенно другая. И такое дробление не только не дает положительного эффекта в плане производительности, но в некоторых случаях даже негативно сказывается на работе с памятью. Поэтому сейчас мы смотрим, как бы лучше соптимизировать такие места, чтобы они у нас эффективно работали не только под Windows, но и под другими ОС (Linux или MacOS). — С чего вообще следует начинать работу с памятью в рамках повышения производительности приложения?Андрей Акиньшин: Первое, с чего всегда нужно начинать, — это с замеров. Я видел очень многих программистов, которые пытаются на взгляд что-то понять («наверняка у нас здесь выделяется слишком много объектов — давайте прямо сейчас начнем вот это место оптимизировать»). Но этот подход, особенно в большом приложении, редко заканчивается чем-то хорошим. Конечно же, нужно выполнять замеры. Есть различные профайлеры памяти для .NET. Например — dotMemory. Это очень хороший инструмент, он позволяет искать утечки памяти, выявлять различные проблемы, смотреть, какие объекты сколько памяти занимают и как они распределены по кучам, поколениям и т.д. Под Windows профайлеров много, и все они меряют достаточно честно. Если мы говорим про Linux/Mac и mono, там инструментарий для профилировки по памяти намного более скудный, не всегда удается померить то, что хочется. — Каких инструментов в плане профилирования вам больше не хватает?
Андрей Акиньшин: В первую очередь — нормального профайлера под Linux и Mac. Например, mono имеет возможности встроенной профилировки — нужно его для этого со специальными ключиками запустить, но возможности там достаточно скудные, работать сложно, результатам можно верить не всегда. С CoreCLR все инструменты по профилированию также находятся в достаточно сыром состоянии. На эту тему много полезной информации в недавних постах Саши Гольдштейна, там рассказывается, как вообще начать с этим работать. Увы, не сказал бы, что есть особое удобство в запуске профайлинг-сессий и анализе результатов. Поэтому лично я жду, когда наконец-то появится удобный кроссплатформенный инструмент для профилирования (памяти в том числе). — Кстати, об эволюции. По мере эволюции .NET и сопутствующего инструментария упрощается ли работа с памятью? Или головной боли становится только больше из-за появления новых механизмов?
Андрей Акиньшин: Я бы сказал, что жизнь постепенно становится лучше. Если мы говорим про Windows, то на полном фреймворке каких-то значимых изменений не было уже достаточно давно, все привыкли к тому, как работает сборщик мусора. Те, кому нужно, знают внутренности и как с ним правильно обращаться, чтобы всем было хорошо. Сейчас набирает популярность кроссплатформенная разработка — под Linux и Mac. И там, к сожалению, с инструментарием не так хорошо. Но постепенно он тоже развивается. Более подробно об оптимизации приложений .NET, в особенности — о работе с памятью и другими компонентами, Андрей Акиньшин расскажет в рамках своего доклада на DotNext 2017 "Поговорим о памяти".
habr.com
Многоцелевая оптимизация. Оптимизация по Парето — Мегаобучалка
Каждый предмет и каждое явление имеют бесконечное число сторон и поэтому полностью могут быть описаны лишь бесконечным числом уравнений с бесконечным числом членов. Таким образом, любое реальное математическое описание предмета или явления носит частичный, приближенный характер, охватывающий лишь некоторые стороны предмета или исследованного явления, при этом не всегда существенные для поставленной цели исследования. Отсюда следует, что представления о любом предмете или любом явлении могут и должны непрерывно уточняться, соответственно могут и должны уточняться и математические зависимости, описывающие эти модели. Число таких приближений и уточнений бесконечно.
При наличии многих, да еще и противоречивых целей, а также различных типов исходной информации системе, естественно, появляются различные альтернативы решения. Термин «альтернатива» имеет ряд синонимов, в зависимости от конкретных особенностей задачи. В частности, употребляются следующие термины: вариант, план, траектория движения системы и др. Среди возможных альтернатив желательно выбрать наилучшую в определенном смысле, или как принято говорить, найти оптимальное решение задачи. При этом даже без особого анализа ясно, что если различные цели противоречивы и не взаимозаменяемы, то их «примирение», отыскание какого-то компромисса очень непростая задача. Кроме того, к противоречивости целей следует добавить еще одно крайне неприятное свойство большой системы – отсутствие достаточно полных сведений как о ней самой, так и о ее взаимодействии с окружающей средой.
Оптимизация по Парето.
В настоящее время понятие множества оптимальных по Парето решений относится к числу основополагающих в общей теории принятия решений. Это множество используется в случаях, когда в многокритериальных задачах разные критерии несопоставимы, или, как обычно говорят, для них отсутствуют какие-либо предпочтения. Это означает, что улучшение решения по одному какому-либо критерию допустимо и оправдано лишь в случае, когда наряду с этим не происходит ухудшения решения хотя бы по одному другому критерию. Под множеством Парето-оптимальных решений понимают такое, когда ни одно из решений этого множества не может быть заменено другим, более хорошим по какому-либо критерию без того, чтобы не ухудшить решение хотя бы по одному другому критерию. Следовательно, каждое решение, принадлежащее множеству Парето, лучше других из этого же множества по каким-то одним и хуже по другим критериям. Так как критерии несопоставимы, то среди этих решений нет ни одного, которое было бы лучше других во всех отношениях. Что же касается решений, не принадлежащих множеству Парето, то все они хуже, по крайней мере, по одному критерию. Именно поэтому множество Парето называют эффективным, и дальнейший поиск с привлечением каких-либо дополнительных условий или процедур естественно выполняется только на множестве Парето.
Поясним сказанное с помощью простейшей задачи, когда имеются два несопоставимых критерия х и y, и оптимизация означает максимизацию обоих критериев (принципиальная сторона вопроса сохраняется и при минимизации).
Пусть все множество допустимых решений образует представленную на рис. 2.1 область, ограниченную осями x и y в положительном квадранте и кривой abcdef (включая и точки, лежащие на этой кривой). При этом будем помнить, что метрики (единицы измерения) критериев x и y несопоставимы. Примем в качестве начальной некоторую альтернативу – точку M с значениями критериев xM и yM. Очевидно, что переход из точки M в одну из точек кривой, ограниченной точками с и f, означает улучшение решения хотя бы по одному критерию без ухудшения по другому. Все промежуточные точки на кривой cf лучше точек внутри области по обоим критериям совместно. Однако переход из точки c в точку f или наоборот невозможен без ухудшения одного из критериев. Все решения, соответствующие точкам на кривой cf, принадлежат множеству Парето-оптимальных решений. При этом каждому решению, соответствующему любой другой точке допустимой области, всегда можно противопоставить не менее одного решения из множества Парето, которое лучше по крайней мере по одному и не хуже по другому критерию. Для случаев нескольких критериев принципиальная картина сохраняется, разумеется, для многомерного пространства критериев.
megaobuchalka.ru
Оптимизация по-русски - Записки журналиста-программиста
Около месяца назад по поселку (напомню — живу я в Вахрушах) поползли слухи — новый главг… главврач нашей больницы решил закрыть детское отделение. Якобы в рамках программы по оптимизации здравоохранения. Дело, по русским меркам, обычно. Действительно, зачем детское отделение в больнице посёлка с населением «всего» чуть больше 10 тыс. человек. Мало ли что свободных коек в этом отделении практически не было — здоровье детей сейчас сами знаете как изменилось.Нет, совсем на улицу детей не выселяют — господин Порошин (дай бог ему здоровья не оказаться в положении его пациентов) выделил детишкам целых 10 коек: между терапевтическим отделении «взрослой» больницы (после инфаркта, инфекционных заболеваний) и гинекологией. Неплохая компания для грудничков. Впрочем, грудничков в больнице теперь вряд ли будет много — койки для них слишком малы. Всем, кто на выделенные койки не поместится новоявленный большой начальник предлагает лечиться дома, а в больницу ходить лишь на процедуры.Кстати, о процедурах. Все, кто бывал в нашей больнице, знают, что бывшее (теперь уже) детское отделение (в котором расположен физеокабинет) и «взрослая» больница находятся в разных корпусах, пристроенных друг к другу. И детям (и их мамам) придётся теперь бегать в физеокабинет через холодное фойе больницы (в добавок — на другой этаж). Весьма сомнительное для простуженных (да и не только) удовольствие.А что же со старым помещением? В нём господин Порошин планирует разместить администрацию больницы — благо, в прошлом году (ещё при старом главвраче, не грешившем такими «оптимизациями») сделали долгожданный ремонт. Туда же (на второй этаж) переехал стоматологический кабинет, приносящий больнице деньги (раньше стоматологи обитали на первом этаже — рядом с прочими врачами поликлиники). А вот вместо стоматологов в маленькое помещение втиснули (так и тянет сказать — «воптимизировали») государственную аптеку, занимавшую непозволительно большое (по мнению руководства) помещение в квартале от больницы (это помещение планируется, по слухам, продать под магазины).Что самое интересное, переместив гос.аптеку поближе к больным (с виду — дело вполне благородное), большой больничный начальник не постеснялся сдать в аренду аптекарям-предпринимателям… Холл больницы, в котором раньше отдыхали и встречались с родственниками стационарные больные.Что же, желание заработать для больницы лишнюю копеечку — похвально. Вот только куда пойдут эти деньги? Стационар всё сокращается, многие специалисты из больницы уходят: уже давненько нет невропатолога, в хирургии нет штатного анестезиолога (до недавнего времени на операции приглашали бывшего анестезиолога, а ныне бизнесмена — теперь, по слухам, и он уже не работает). По логике, эти сокращения должны были высвободить бюджетные средства, коих по словам Порошина катастрофически не хватает. Однако же, никаких улучшение в положении прочих подразделений больницы не видно. Так куда уходят деньги? И стоит ли жаловаться на их нехватку человеку, чья прямая обязанность — этих самых денег выбивание? Чем жаловаться на нехватку денег и отыгрываться на пациентах (тем более — детях!), лучше бы работал. Почему-то у всех предшественников господина Порошина сил на это хватало — как бы плохо не жилось больнице, закрывать ничего не приходилось.Заставляет задуматься, знаете ли.
PS. Сегодня про многое из рассказанного мною поведал «9 канал» в сюжете «Давеча». Кому интересно — вот ссылка на материал.
PPS. Хотелось бы верить, что кировские власти когда-нибудь перестанут выдвигать в начальники местного уровня личностей, для которых интересы других людей не стоят ломаного гроша. Это относится не только к нашей больнице.
petrochenko.ru
