Pull to refresh
11
0

Пользователь

Send message
Сложно всё уместить в одну статью.
Реестр рисков, безусловно, был. Часть этих рисков указана в статье. Тут, к примеру, травмы (частое явление), сильный ветер во время гонки, отсутствие (исчезновение) бюджета и многое другое. Изменения тоже были. Например, я готовился к гонке в Малайзии, но попутно «нарисовалась» гонка в Амстердаме, которую я рассматривал как «пробную». Пришлось менять план, пришлось раньше намеченного покупать велосипед для Time trial и т.д.
На самом деле в статье не указано очень много деталей. Все аспекты подготовки займут целую книгу (сейчас как раз пытаюсь её писать). Ещё важная тема, не затронутая тут, — здоровье.
Что касается питания, то по большому счёту серьёзных изменений в этом плане не было. Я просто стал питаться чуть более правильно: меньше жирного, почти отказался от свинины, больше белков, меньше сладостей (быстрых и ненужных углеводов), меньше еды на ночь (а впоследствии вообще отказался от еды поздним вечером), больше стал поглощать воды. Много знакомых триатлетов становятся вегетарианцами. Я в эту сторону не смотрю даже. Люблю мясо. Лучше стейка может быть только хороший стейк.
Так что незначительные изменения в питании никак не повлияли на бюджет. Разве что стоит упомянуть о витаминах, которые несколькими курсами мне пришлось поглощать в силу большого количества тренировок. Но это не сильно влияет на бюджет.
Будем благодарны за обратную связь по результатам ваших тестирований.
Один из наиболее часто встречающихся на практике подходов – выделение трех дисков (1- под ОС, второй – под файлы данных, 3 – под журналы). Этот вариант предлагается обычно администраторами баз данных, не знакомыми с SharePoint. Те, кто понимает специфику работы на портале и возникающую нагрузку по обработке данных, еще учитывает другую информацию. Примеров можно привести массу, рассмотрю лишь два:
Кейс 1. В случае развертывания портала в базовой конфигурации и небольших пропорциональных нагрузках по чтению/записи контента, работе с файлами небольших размеров и обеспечении стандартных возможностей поиска разбиения между двумя дисками файлов данных и журналов вполне хватает. В случае же большого кол-ва файлов (к примеру, 1 млн), повышения требований ко времени обхода контента, производительности поиска, — без переноса файлов данных и журналов службы поиска на другие диски уже не обойтись из-за явно наблюдаемых проблем производительности.
Кейс 2. Если на портале реализован функционал по массовой обработке элементов списков/библиотек, обработке XML и тп, то существенно повышаются требования к скорости чтения/записи для базы данных tempdb и базе контента.
SharePoint изначально ориентирована на обработку большого кол-ва конкурирующих запросов, в связи с чем для параметра max degree of parallelism вендор рекомендует установить значение 1. Более того, если будет установлено иное значение, то будут блокироваться операции создания баз данных SharePoint. Подробнее можно прочитать здесь.
В первой части статьи, посвященной тюнингу SQL Server под SharePoint даются рекомендации относительно действий и настроек, которые выполняются еще до начала инсталляции SQL, и, тем более, SharePoint. Описание особенностей настройки параметров в ходе инсталляции SQL Server, а также параметрами и настройками непосредственно до инсталляции SharePoint и после нее будут описаны во второй части, выход которой ожидается 10.04.2017. Во второй части речь пойдет и о maximum degree of parallelism, и о коэффициенте заполнения индекса, и о многих других настройках.
Ранжирование дисков по скоростям выполняется на основе проведения тестов, в этом отношении каждую конкретную среду можно считать уникальной. Рекомендация по распределению файлов данных и файлов журналов транзакций для баз данных SharePoint учитывает особенности выполнения операций чтения/записи в файлы данных, в файлы журналов транзакций, а также типовые различия в интенсивности этих операций в отношении разных служб и компонентов SharePoint. Обязательным является предварительный анализ характера работ на портале.
Если говорить о моделях восстановления баз данных SQL-сервера, то используем стандартные названия «простая», «полная» и «с неполным протоколированием».
На практике при работе с локализованными последними версиями SQL-сервер встречаются непривычные нам подмены названий параметров и опций, на счастье без искажений сути. Очень не люблю локализации, но с ними приходится работать. В статье использованы реальные названия параметров и значения одной из таких локализаций.
В случае SharePoint отладке работы с TCP/IP Chimney Offload следует уделить внимание при работе веб-приложений по SSL и активном обращении пользователей к файлам больших размеров (видео, аудио).
Размер кластера в 64Кб коррелируется с размером экстента, — одной из основных единиц организации хранения данных SQL-сервером. Более подробно о страницах и экстентах можно прочитать здесь.
Вендор не выдвигает прямого требования о соответствии между размерами кластеров на хостовой машине и виртуальной. Если есть возможность, то выполняют тестирование обоих вариантов, после чего выбирают с наиболее высокими показателями производительности.
Выравнивание разделов остается одной из рекомендаций, которая справедлива для всех версий ОСЦ Windows и для всех версий SQL Server, включая SQL Server 2012 и SQL Server 2014. Исключений нет.
При работе с ОС Windows Server 2008 и более поздними версиями, в ходе управления дисками средствами графического интерфейса выравнивание разделов выполняется автоматически. Несмотря на это на практике регулярно встречаются ситуации, когда системные администраторы вручную управляют разделами жестких дисков, не задумываясь о необходимости соблюдать корреляцию между Partition Offset, File Allocation Unit Size, Stripe Unit Size (в случае последующей работы с SQL Server). Если корреляция нарушена, это оказывает существенное влияние на производительность в ходе выполнения операция чтения/записи. В связи с этим вендором настоятельно рекомендуется обязательно проводить проверку выравнивания разделов перед инсталляцией любой из версий SQL Server.
Более подробно вы можете прочитать об этом, например, в статье.
1. Самое важное здесь — правильно передать права на программу для ЭВМ фирме, которая будет заниматься продажей этого софта. Это может быть лицензионное соглашение, а может быть полная передача прав таким образом, чтобы фирма, созданная для продажи, стала полным правообладателем ПО.
2. Хорошая идея, в целом. Оставлю это как идею для будущего поста.
3. К сожалению, про многие страны не знаю, но в целом и общем схема приблизительно такая же в некоторых.
4. Никакой разницы в жанре ПО для целей его надлежащего оформления нет. Программа для ЭВМ — это результат интеллектуальной деятельности, и не имеет значения, какой он направленности.
5. Крайне сложный вопрос, ответить на который очень коротко я не смогу. Функционал – это, по сути, идея, то, что должен уметь делать софт. Программ с аналогичным функционалом – множество (к примеру, MS Office, Мой Офис, офисные продукты от Apple и др.). Авторское право на идею не распространяется. Поэтому никто не запрещает разрабатывать у другого работодателя ПО с аналогичным функционалом. Но код должен быть иным, интерфейс и т.д.
Безусловно, ЗП и вознаграждение – это юридически разные вещи, поэтому чтобы «два раза не вставать», всегда проще определиться с этим раз и навсегда для работника и работодателя в соглашении между ними. Как правило, формулировки такого соглашения сводятся к тому, что авторское вознаграждение включено в заработную плату либо выплачивается как премия. Здесь я сторонник не усложнять.
На самом деле всё очень просто: нужно понять базовый принцип. Я в статье, скорее, говорил о запущенных случаях. Безусловно, можно оптимизировать и включить в трудовые договоры со ВСЕМИ сотрудниками положения, которые освободят от почти половины озвученных в статье бумажек и документов. Нужно иметь в виду, что мы хотим защититься и постараться минимизировать споры о правах на ПО. Поэтому лучше «закрыться» бумажками.
Не смогу ответить универсально на этот вопрос. Нужно внимательно ознакомиться с лицензионным соглашением. Если лицензия позволяет свободно дорабатывать и использовать доработку как свой софт, то на баланс можно ставить, безусловно. Стоимость точно так же определяется как и в случае с полностью своей разработкой.
По Вашему вопросу №2: софт включить в баланс можно. Это не зависит от того, должны были или не должны в рамках должностных обязанностей сотрудники заниматься разработкой ПО. Должны или не должны – это вопрос к последующему оформлению и возникновению прав на ПО, но это никак не влияет на постановку на баланс в качестве нематериального актива.
Ну, и по вопросу № 3 ответ тот же.
Приведу пару типовых ситуаций из практики, когда активно использовался файл подкачки, обеспечивший возможность продолжить работу с корпоративным порталом вместо сбоя в работе отдельных компонентов или сервисов:

Пример 1. Ресурсоемкие операции загрузки файлов больших размеров, воспроизведение видео на портале, обход контента службой поиска, кастомные решения, связанные с обработкой списков и библиотек с большим кол-вом элементов/файлов и многие другие нередко приводят к резким всплескам объемов используемой памяти. В одно прекрасное утро HR разместили новость, содержащую видео длительностью около 10 мин на главной странице портала, с утра практически одновременно ее решили просмотреть порядка 600 человек, при этом ввиду ошибки в действиях системного администратора в тот же период времени был запущен полный обход контента службой поиска, обычно занимавший 2-2,5 часа. При этом сервис новостей являлся бизнес-критичным, т.к. публиковались выступления топ-менеджеров, знакомство с которыми должно было проходить в течение 1-2 дней после публикации. Ранее работа портала была стабильна и особых проблем не возникало, на серверах по 16 Гб ОЗУ. За счет наличия файла подкачки внезапный всплеск нагрузки прошел почти безболезненно, сервис продолжил работу. Были отдельные обращения о снижении скорости работы на портале. У системного администратора была возможность проанализировать причины и остановить обход.

Пример 2. Более 15 000 пользователей портала, активно осуществляющих поиск по порталу. Этот сервис бизнес-критичный. В системе развернули несколько новых решений под SharePoint, работа которых была связана с обработкой больших списков (содержащих большое кол-во элементов). Ввиду особенностей выделения сегментов памяти CLR и сборки мусора приложениями ASP.Net возможны ситуации постепенного нарастания зарезервированных объемов памяти, требуемые для работы одного и того же приложения, проявляющиеся постепенно, и нарастающие со временем. С точки зрения конечных пользователей это проявляется, как правило, в постепенном снижении производительности при работе на корпоративном портале. В корпоративной сети применили новую групповую политику, в результате чего были урезаны в правах некоторые учетные записи. Каких-либо ошибок не наблюдалось при работе на портале, но решения предусматривали дополнительные действия и ведение журналов и запись сообщений об ошибках при возникновении исключений. Оперативно увеличить объем ОЗУ не представлялось возможным, клиенту обратился с просьбой оперативно выяснить у устранить причины заметного снижения производительности работы на портале. Время на коммуникации плюс время на работу специалиста на анализ причин, плюс внесение изменений в настройки AD. Весь этот временной промежуток работа пользователей на корпоративном портале продолжалась.
150%, указанное мною и рекомендуемое Майкрософт, на практике хорошо себя зарекомендовали. Обычно этих пределов достаточно для того, чтобы выиграть время и принять решение относительно какой-то внештатной ситуации. Подчеркну, что эта рекомендация дана в привязке к типовым размерам ОЗУ на серверах SharePoint (16-24-32).
На практике в фермах на SharePoint-серверах обычно 16-24-32 Гб ОЗУ. Очень редко на серверах приложений 48 ГБ и крайне редко 64 Гб (за всю практику лишь один или два раза столкнулась). О сотнях ГБ ОЗУ и речи не идет. Вопрос масштабирования и распределения нагрузки на практике успешно решается добавлением дополнительных серверов с ролями (Web Front End, Web application и/или другими в зависимости от того, какого рода нагрузку желают распределить, — обработку обращений пользователей, увеличить производительность работы конкретного приложения-службы и т.д.). Соответственно, случай огромных размеров файла подкачки исключим из обсуждения.
Использование файла подкачки всегда будет наносить ущерб производительности ввиду того, что скорость работы с ОЗУ существенно превышает работу с дисковой подсистемой.

Многочисленные службы и компоненты SharePoint (веб-приложение корпоративного портала, процессы, обеспечивающие работу службы поиска, службы Excel, системные задания и др.) активно работают с данными и используют память. Платформа SharePoint, действительно, имеет свои особенности, связанные с тем, что это ASP.Net x64 веб-приложение (в основе .Net Framework 4.x), что означает вполне конкретную архитектуру, важным компонентом которой является среда исполнения кода (CLR). CLR использует специализированные механизмы управления выделением и перераспределением сегментов виртуальной памяти. Работа служб, компонентов, обработка пользовательских запросов на портале, — все эти действия связаны с обработкой серверного кода, содержащего обращение к всевозможным объектам внутри этого кода. Даже в случае отсутствия утечек памяти ввиду ошибок в коде, допущенных разработчиками, удаление объектов из оперативной памяти специальным компонентом CLR, — сборщиком мусора, — не гарантирует моментальное освобождение сегментов памяти. Существует временной разрыв между двумя этими операциями из-за особенностей работы сборщика мусора. С учетом особенностей работы служб и компонентов SharePoint, CLR Майкрософт рекомендует размер файла подкачки и его размер – не мене 100% от размера ОЗУ, что связано с тем, что при таком соотношении сборщик мусора меньше использует управляемую память и меньше нагружает ЦП.

Средства ОС Windows Server позволяют настроить параметры виртуальной памяти так, чтобы вообще не использовался файл подкачки. Да, вы можете увеличить объем ОЗУ, оставив без изменений ранее установленный размер файла подкачки. Поддерживать всегда соотношение 1:1 или 1:1,5 не является строго обязательным для всех без исключений размеров ОЗУ на серверах SharePoint и носит рекомендательный характер. В случае, если файл подкачки не используется или его размер минимален, у ОС теряется всякая возможность выгружать данные неактивных процессов из ОЗУ на диск и возврат обратно при продолжении работы с нею или она серьезно ограничена. Наличие файла подкачки позволяет более управлять размещением данных, востребованных в тот или иной момент времени, обеспечивая более эффективное использование быстродействующей ОЗУ в случае возникновения потребностей приложений, превышающих объем этой ОЗУ.
Если себестоимость больше одного рубля, то я бы не рекомендовал её указывать в размере 1 руб. Не исключена вероятность, что такая заниженная сумма вызовет вопросы у налоговых органов. Что касается завышения, то в этом случае я не вижу проблем, поскольку это вопрос оценки. Если Вы оцениваете программу больше себестоимости разработки, то вы повышаете стоимость компании (капитализации).
Все рекомендации, данные в статье необходимо рассматривать строго в контексте платформы SharePoint, работающей по особым правилам. Сервера SharePoint (Web Front End, Application и др.), — это, прежде всего, веб-приложения ASP.Net, обеспечивающих обработку серверного кода. Требования к настройке параметров виртуальной памяти, — это не прихоть, а необходимость, основанная на сообенностях хранения и обработки данных в ходе работы веб-приложений. Более того, проверка правила соответствия настроек указанным мною рекомендациям реализована анализатором работоспособности, сообщения которого вы можете найти в Центре Администрирования. Ссылки для более подробной информации: SharePoint Health Analyzer rules reference, KB-статья.
Соглашусь, что показания счетчика Buffer Cache Hit Ratio, как правило, стабильны. В мониторинг рекомендуем включать для того, чтобы иметь возможность фиксировать реальную проблему, — падение значения ниже 90-95%. Наиболее важный показатель, действительно, Page Life Expectancy. 300 мс – это базовый ориентир для показания этого счетчика. В данной конкретной системе он может отличаться, но значения показателя должны быть стабильны во времени. Любые серьезные скачки не должны оставаться без внимания. В дополнение к приведенной в комментарии ссылке добавляю еще одну.
RAID-массивы часто включают в себя большое количество дисков, обеспечивая работу с ними как с едиными диском с точки зрения конечного пользователя, высокий уровень отказоустойчивости и производительности. Для RAID-массивов первоначальным ориентиром должна служить длина очереди, менее чем в 1,5-2 раза больше количества шпинделей в массиве.
Обращу особое внимание на то, что показания данного счетчика нельзя рассматривать в отрыве от других. Наиболее важным дополнительным показателем являются данные о задержках Более подробную информацию можно получить, например, здесь и здесь.
Все рекомендации, данные в статье необходимо рассматривать строго в контексте платформы SharePoint, работающей по особым правилам. Сервера SharePoint (Web Front End, Application и др.), — это, прежде всего, веб-приложения ASP.Net, обеспечивающих обработку серверного кода. Требования к настройке параметров виртуальной памяти, — это не прихоть, а необходимость, основанная на сообенностях хранения и обработки данных в ходе работы веб-приложений. Более того, проверка правила соответствия настроек указанным мною рекомендациям реализована анализатором работоспособности, сообщения которого вы можете найти в Центре Администрирования. Ссылки для более подробной информации: SharePoint Health Analyzer rules reference, KB-статья.
GreenStore, это здорово, что Вы зашли на наш сайт и разместили тут фото наших сотрудниц, но среди них нет фото Анны :)

Information

Rating
Does not participate
Date of birth
Registered
Activity