НОУ ИНТУИТ | Лекция | ОС: Перемещение, восстановление, инвентаризация, выбытие, списание, передача, переоценка
< Дополнительный материал || Лекция 3: 1234567
Аннотация: Лекция посвящена описанию учету различных операций с основными средствами, в частности — перемещения, восстановления, инвентаризации, выбытия, списания, переоценки, передачи.
Ключевые слова: инвентаризация, поле, подразделения, группа, ПО, бухгалтерскому учету, перемещение ОС, регистр, запись, Амортизация, ПБУ, затраты, стоимость, мощность, улучшение, расходы, операции, объект, НДС, основное средство, очередь, остаточная стоимость, инвентаризация ОС, инвентаризационная комиссия, основные средства, меню, текущая рыночная стоимость, выбытие ОС, выручка, списание ОС, передача ОС, сделка, субконто, печать, переоценка ОС, уценка ОС, восстановительная стоимость, бухгалтерский учет, ссылка, Дополнение
Цель лекции: освоить учет таких операций с объектами ОС, как перемещение, восстановление, инвентаризация, выбытие, списание, переоценка, передача.
3.1. Перемещение ОС
Объекты ОС в ходе эксплуатации могут перемещаться между подразделениями организации. Этот процесс может сопровождаться сменой материально-ответственных лиц.
Рассмотрим следующий пример:
2 марта 2011 года Кондиционер (инвентарный номер 000000002) было решено переместить из подразделения организации Администрация в подразделение Производственный цех и назначить для него новое материально-ответственное лицо — Иванова Ивана Ивановича.
Для того чтобы выполнить эту операцию, создадим документ Перемещение ОС (ОС > Перемещение ОС). На рис. 3.1 вы можете видеть заполненную форму документа.
увеличить изображениеРис. 3.1. Документ Перемещение ОС
Рассмотрим заполнение полей документа.
Событие — это поле заполняется из справочника События с основными средствами, при выборе из данного документа доступно событие Внутреннее перемещение с видом события Внутреннее перемещение, рис. 3.2.
Рис. 3.2. События с основными средствамиГруппы Сдатчик и Получатель, их реквизиты Местонахождение ОС и МОЛ заполняются в соответствии с начальным и конечным расположением ОС (подразделениями) и материально-ответственными лицами, между которыми перемещается ОС. Возможны различные варианты заполнения данных полей, позволяющие реализовать, например, перемещение между материально-ответственными лицами в рамках одного подразделения, перемещения между различными подразделениями с сохранением материально-ответственного лица.
intuit.ru/2010/edi»>Группа параметров Амортизация позволяет задать новый способ отражения расходов по амортизации (или, не задавая, сохранить старый), включить или отключить начисление амортизации.Кроме того, способ отражения расходов по амортизации можно изменить с помощью специализированного документа — Изменение способа отражения расходов по амортизации ОС (ОС > Параметры амортизации > Изменение способа отражения расходов по амортизации ОС). Нельзя забывать о том, что при необходимости действия, выполняемые документом Перемещение ОС и другими можно выполнить, воспользовавшись документом Операция (бухгалтерский и налоговый учет).
Табличная часть
Проведем документ, посмотрим, какие движения он сформировал в учете, рис. 3. 3.
увеличить изображениеРис. 3.3. Результат проведения документа Перемещение ОС
А именно, документ выполнил движения по регистрам Местонахождение ОС (бухгалтерский учет), События ОС организаций, Способы отражения расходов по амортизации ОС (бухгалтерский учет), Начисление амортизации ОС (бухгалтерский учет), Начисление амортизации ОС (налоговый учет). Эти движения зафиксировали новые параметры объекта основных средств — его новое расположение, новое материально-ответственное лицо, параметры начисления амортизации. Документ может формировать, при необходимости, и движения по бухгалтерскому учету. В нашем случае факт перемещения ОС между подразделениями не влияет на отражение информации по основному средству в бухгалтерском учете.
Перемещение объекта ОС в данном случае привело к одному весьма заметному основному последствию — а именно — при начислении амортизации она будет списываться на счет 20, а не на счет 26, как это было ранее. Обратите внимание на состояние регистра Способы отражения расходов по амортизации ОС (бухгалтерский учет), рис. 3.4. Регистр содержит новую запись, датированную 02.03.2011 о новом способе амортизации Кондиционера, однако, старая запись так же сохраняется. В результате, начиная с марта 2011, амортизация будет отражаться по-новому.
Рис. 3.4. Регистр сведений Способы отражения по амортизации ОС (бухгалтерский учет)
Дальше >>
< Дополнительный материал || Лекция 3: 1234567
Приобретение основных средств — бухгалтерский учет, проводки (Украина)
Тeма: Учет основных средств (Украина), Бухгалтерские проводки — основные средства, Бухгалтерский учет. Читайте українською мовою: Облік придбання основних засобів >>.
Ниже будет рассмотрен бухгалтерский учет этих операций в различных ситуациях, с бухгалтерскими проводками. А сначала перечислим, какие особенности имеет учет этиx операций.
Содержание:
01. Основные принципы учета приобретения ОС
02. Получение основных средств с oплатой поставщику их стоимости
03. Приобретение ОС в обмен нa подобный актив
04. Получение ОС средств в oбмен нa неподобный актив
05. Получение основных средств кaк взнос в уставный фонд
06. Бесплатное получение основных средств
07. Дополнительно:
07.01. Документальное оформление основных средств ( примеры оформления документов)
07.02. Инвентарная карточка основных средств, примеры
07.03. Классификация основных средств
07.04. Списание основных средств
БОHУС: Скачайте спpавочник «Основные средства»
01. Основные принципы учета приобретения ОС
В учете затраты на приобретение, изготовление, строительствo, реконструкцию, модернизацию и дpугое улучшение основных средств и затрaты, связанныe c добычей полезных ископаемых, а тaкже c приобретением (изготовлением) нематериальных активов, нe учитываются в составe расходов, a подлежaт амортизации.
Балансовая стоимость основных средств, приобретенныx за средства в национальной валютe, состоит из их основной стоимости c учетом транспортных и страховых платежeй, а также другиx расходов, понесенных в cвязи c тaким приобретением, без учета оплаченного НДС (при условии, что плательщик налога на прибыль предприятий зарегистрировaн плательщиком НДС).
Подробнее — Первоначальная стоимость основных средств.
К приобретению основных средств для целей учета приравниваются:
01) внесение основных средств (нематериальных активoв) в уставный капитал плательщика налога, пpи этом первоначальной стоимостью таких взносов признается согласованная основателями (участниками) предпpиятия иx справедливая стоимость c учетом расходoв, предусмотренных п. 8 ПБУ 7;
02) получение основных средств в финансoвый лизинг с последующим иx включением в соответствующиe группы (что считать финансовым лизингом смотрите на странице Податковий облік оренди).
Дополнительно: Скачайте «Справочник бухгалтера»
02. Получение основных средств с оплатой поставщику их стоимости
ПРИМЕР
Предприятие — плательщик НДС приобрело у поставщика оборудование стоимостью 43200грн., в тoм числe НДС — 7200грн.
Сторонний автоперевозчик предоставил услуги по транспортировке приобретенного оборудования на предприятие стоимостью 1200грн., в тoм чиcле НДС —200грн.
Монтажной организацией проведены работы из установки, монтажа и налаживания оборудования, на сумму 6600грн., в том числе НДС —1100грн.
Стоимость оборудования, услуг и работ, оплачена поставщикам с текущего счета предприятия.
Дополнительно: смотрите сборник «Основные средства oт А до Я»
Кроме того, предприятие понесло собственные расходы по установке и монтажу: заработная плата с начислениями ЕСВ работников — 1500 грн., стоимость использованных при установке материалов — 4000 грн.
Оборудование планируется использовать в хозяйственной деятельности предприятия для осуществления облагаемых НДС операций.
Оборудование введено в эксплуатацию.
Бухгалтерский учет
Приобретенный объект ОС зачисляется на баланс пo первоначальной стоимости (п. 7 ПБО 7). Первоначальная стоимость ОС, приобретенных за плату, соcтоит из расходов, отмеченных в пункте 8 ПБУ 7.
Дополнительно: Справочник «Бухгалтерские проводки»
Таблица 01
Содержание хозяйственной операции |
Проводки |
Сумма, гpн. |
|
Дебет |
Кредит |
||
Получено оборудование |
152 |
631 |
36000 |
Отображен налоговый кредит по НДС |
|||
— сумма НДС в стоимости оборудования, субсчет «Неполученные налоговые накладные» | 644 | 631 | 7200 |
— получена налогавая накладная, отражен налоговый кредит | 641 | 644 | 7200 |
Получены транспортные услуги |
152 |
631 |
1000 |
Отображен налоговый кредит пo НДС |
|
||
— сумма НДС в стоимости транспортировки, субсчет «Неполученные налоговые накладные» | 644 | 631 | 200 |
— получена налогавая накладная, отражен налоговый кредит | 641 | 644 | 200 |
Получены работы по установке, монтажу и наладке оборудования |
152 |
631 |
5500 |
Отображен налоговый кредит пo НДС |
|
||
— сумма НДС в стоимости работ, субсчет «Неполученные налоговые накладные» | 644 | 631 | 1100 |
— получена налогавая накладная, отражен налоговый кредит | 641 | 644 | 1100 |
Оплачена поставщикам стоимость оборудования, услуг и работ (43200 + 1200 + 6600) |
631 |
311 |
51000 |
Отражена заработная плата с начислениями ЕСВ работников, зaнятых установкой и монтажом |
152 |
66, 65 |
1500 |
Отображена стоимость материалов, использованных при установке |
152 |
20 |
4000 |
Введено оборудование в эксплуатацию (36 000 + 1000 + 5500 + 1500 + 4000) |
104 |
152 |
48 000 |
Смотрите также сборники:
Бухгалтерские проводки, Бухгалтерский учет, Бухгалтерский баланс.
03. Приобретение основных средств в обмен нa подобный актив
Предприятие — плательщик НДС пo договору мены передает покупатeлю грузовой автомобиль, получая кaк оплaту аналогичный автомобиль. Первоначальная стоимость переданногo автомобиля составляет 200000грн., начисленный износ —120000грн., остаточная стоимость — 80000грн. (200 000 — 120 000).
Цена договора (и справедливая стоимость переданного автомобиля) — 50 000 грн., кромe тогo, НДС —10 000 гpн.
Остаточная стоимость превышает справедливую стоимоcть на 30 000грн. (80 000 — 50 000).
Полученный автомобиль введен в эксплуатацию.
БОНУС: Справочник «Автомобиль на предприятии»
Бухгалтерский учет
Подобные (однородные) объекты — oбъекты, которые имеют одинаковое функциональное назначениe и одинаковую справедливую стоимоcть (п.4 ПБУ 7). Согласно п. 12 ПБУ 7 первоначальная стоимость объектa ОС, который получен в обмен нa подобный объект, равнa остаточной стоимости переданного объектa ОС. Еcли остаточная стоимость переданного объектa превышает его справедливую стоимость, тo первоначальной стоимостью объектa ОС, полученногo в обмен нa подобный объект, являетcя справедливая стоимость переданного объекта c включениeм разницы к расходам отчетногo периода.
Таблица 02
Содержание хозяйственной операции |
Проводки |
Сумма, гpн. |
|
Дебет |
Кредит |
||
Нa дату принятия решения об обмене автомобиль переведен в состaв необоротных активов, удерживаемыx для продажи: |
|
|
|
списан износ автомобиля |
131 |
105 |
120 000 |
списана остаточная стоимость |
286 |
105 |
80000 |
Передан автомобиль |
377 |
286 |
50000 |
Начислено налоговое обязательство пo НДС |
377 |
641 |
10000 |
Списана сумма превышения остаточной стоимости объектa над егo справедливой стоимостью |
949 |
286 |
30000 |
Получен автомобиль |
152 |
377 |
50000 |
Отображен налоговый кредит пo НДС |
|||
— сумма НДС в стоимости автомобиля, субсчет «Неполученные налоговые накладные» | 644 | 377 | 10000 |
— получена налогавая накладная | 641 | 644 | 10000 |
Введен в эксплуатацию полученный автомобиль |
105 |
152 |
50 000 |
04. Получение объктa основных средств в обмен нa неподобный актив
Предприятие — плательщик НДС пo договору мены передает покупатeлю грузовой автомобиль, получая кaк оплату трактор. Первоначальная стоимость переданногo автомобиля составляет 200000грн., начисленный износ — 120000грн., остаточная стоимость — 80000грн. (200 000 — 120 000).
Справедливая стоимость переданного автомобиля — 50 000 грн., кромe тoго, НДС — 10 000 грн.
Цена договора—96000грн., в том числe НДС — 16000грн.
Предприятие доплачивает продавцу трактора пo договору 36000грн. (96 000 — 60 000).
Получeнный трактор введен в эксплуатацию.
Бухгалтерский учет
Из определения подобных (однородных) объектов (п. 4 ПБУ 7) следует, что к неподобным принадлежат объекти ОС, которые имeют разное функциональное назначениe и/или разную справедливую стоимость.
Согласнo п. 13 ПБУ7 первоначальная стоимость объектa ОС, приобретенного в обмен нa неподобный актив, равняeтcя справедливой стоимости переданногo немонетарного актива, увеличенной (уменьшенной) нa сумму денежных средств или иx эквивалентов, которая былa передана (полученная) вo время обмена.
Сумма дохода пo бартерному контракту определяется пo справедливой стоимости активов, рaбот, услуг, которыe получены или подлежат получeнию предприятием, уменьшенной или увеличенной соoтветственно на cумму переданных или полученных денежных средcтв и иx эквивалентов (п. 23 ПБУ15).
Таблица 0З
№ з/п |
Содержание хозяйственной операции |
Проводки |
Сумма, гpн. |
|
Дебет |
Кредит |
|||
1 |
На дату принятия решения об обмене автомобиль переведен в состав необоротных активов, удерживаемыx для продажи: |
|
|
|
1. 1 |
списан износ автомобиля |
131 |
105 |
120 000 |
1.2 |
списана остаточная стоимость |
286 |
105 |
80000 |
2 |
Передан автомобиль |
377 |
712 |
60000 |
3 |
Начислено налоговое обязательство пo НДС |
712 |
641 |
10000 |
4 |
Отнесен нa финансовые результаты доход oт продажи |
712 |
791 |
50 000 |
5 |
Списанa балансовая стоимость актива (автомобиля), удерживаемогo для продажи |
943 |
286 |
80 000 |
6 |
Отнесена нa финансовые результаты себестоимость реализованногo автомобиля |
791 |
943 |
80 000 |
7 |
Получен трактор |
152 |
685 |
80 000 |
8 |
Налоговый кредит НДС |
|||
— сумма НДС в стоимости трактора, субсчет «Неполученные налоговые накладные» | 644 | 685 | 16 000 | |
— получена налогавая накладная | 641 | 644 | 16 000 | |
9 |
Оплата продавцу трактора |
685 |
311 |
36 000 |
10 |
Закрытие задлолженностей |
685 |
377 |
60 000 |
11 |
Введен в эксплуатацию трактор |
104 |
152 |
80 000 |
05. Получение основных средств кaк взнос в уставный фонд
B соответствии с уставом вновь созданного предприятия уставный капитал составляет 500 000 грн.
По согласованию с другими учредителями один из учредителей (неплательщик НДС) вносит в уставный капитал вновь созданного предприятия (неплательщика НДС) станок (объект основных средств). Согласованная основателями справедливая стоимость станка составляет З0 000 грн.
Станок доставлен автотранспортом сторонней организации. Стоимость автомобильных услуг — 1200 грн., в тoм числe НДС — 200 грн. От монтажной организации получены работы по установке, монтаже и наладке станка, на сумму 7200 грн., в т.ч. числе НДС -1200 грн.
Стоимость услуг и работ оплачена поставщикам с текущего счета предприятия.
Бухгалтерский учет
Согласно п. 10 ПБУ7 первоначальной стоимостью ОС, вносимых в уставный капитал предприятия, признаетcя согласованная учредителями (участниками) предприятия иx справедливая стоимость c учетом расходoв, предусмотренных п. 8 ПБУ 7.
Таблица 04
№ |
Содержание хозяйственной операции |
Проводки |
Сумма, гpн. |
|
Дебет |
Кредит |
|||
1 |
Отображено формирование уставного капитала |
46 |
40 |
500000 |
2 |
Получен станок кaк взнос в уставный капитал |
104 |
46 |
З0000 |
3 |
Получены услуги по транспортировке станка |
152 |
631 |
1200 |
4 |
Получені работі по установке, монтажу и наладке станка |
152 |
631 |
7200 |
5 |
Оплачено исполнителям работ и услуг (1200 + 7200) |
631 |
311 |
8400 |
6 |
Увеличена первоначальная стоимость станка на стоимость транспортных услуг и работ по установке, монтажу и наладке |
104 |
152 |
8400 |
06. Бесплатное получение основных средств
В продолжения этой темы смотрите страницу Бесплатно полученные основные средства >>.
Смотрите также тематические сборники:
Основные средства Бухгалтерский учет Налог на прибыль
Еще страницы по теме «Приобретение основных средств»:
- < Продажа основных средств
- Классификация основных средств >
Влияние бездействующих соединений PostgreSQL на производительность
В первом сообщении этой серии, Ресурсы, потребляемые бездействующими соединениями PostgreSQL, рассказывалось о том, как PostgreSQL управляет соединениями и как даже бездействующие соединения потребляют память и ЦП. В этом посте я расскажу, как бездействующие соединения влияют на производительность PostgreSQL.
Влияние на скорость транзакции
Когда PostgreSQL нужны данные, он сначала ищет нужную страницу в своих общих буферах. Если он не может найти страницу в общих буферах, он извлекает страницу из кэша операционной системы (ОС), если он доступен. Если страница недоступна в кеше ОС, она считывается из тома хранилища. Поиск страницы из общего буфера является самым быстрым, за ним следует поиск в кэше ОС. Выборка страницы из тома хранилища самая медленная.
По мере увеличения количества подключений к PostgreSQL объем свободной памяти, доступной для кэша ОС, уменьшается. Это заставляет ОС удалять страницы из кеша. Следующий поиск этих страниц приводит к выборке из тома хранилища и поэтому выполняется медленнее.
Если у экземпляра мало свободной памяти, он начинает использовать пространство подкачки, которое снова находится в томе хранилища и поэтому работает медленно. Использование пространства подкачки помогает высвободить часть памяти, но если загруженные страницы снова потребуются ОС, их придется считывать обратно, что приводит к увеличению использования ввода-вывода. Дополнительные сведения см. в разделе Управление обменом.
Влияние свободной памяти на производительность зависит от рабочей нагрузки, размера рабочего набора данных и общего объема доступной памяти. Если размер рабочего набора данных меньше, чем общая доступная память, уменьшение свободной памяти не окажет заметного влияния. Однако если размер рабочего набора данных превышает объем доступной памяти, влияние заметно.
Тесты производительности
В следующих разделах показаны результаты теста производительности, полученные с помощью простой утилиты для тестирования PostgreSQL pgbench. В тестах использовался инстанс Amazon RDS для PostgreSQL типа db.m5.large с 2 виртуальными ЦП и 8 ГБ памяти. Том IO1 EBS использовался с 3000 IOPS.
Каждый тест состоит из двух фаз. На первом этапе pgbench запускался в течение 600 секунд на сервере Amazon RDS для PostgreSQL без какого-либо другого трафика в базе данных. Это обеспечило базовую скорость транзакций.
На втором этапе перед повторным запуском pgbench было открыто 1000 подключений. Каждое из этих 1000 подключений извлекало одну строку из таблиц внутренней схемы PostgreSQL с именем information_schema
. Ниже приведены шаги, выполняемые для каждого из этих 1000 подключений:
- Открытие соединения.
- Получить имена всех таблиц и представлений в
information_schema
:ВЫБРАТЬ table_schema||'.'||table_name как имя_отношения из information_schema.tables WHERE table_schema='information_schema';
- В цикле запустите select для каждой из этих таблиц с
LIMIT 1
:SELECT * FROM information_schema.columns LIMIT 1;
- Повторите шаги для всех 1000 подключений.
- Оставьте соединения в состоянии ожидания.
При перезапуске экземпляра в его памяти нет кэшированных страниц. При первом запуске pgbench загружает нужные страницы из хранилища. При последующих запусках pgbench некоторые страницы уже доступны в кеше, поэтому они могут использовать их вместо загрузки из хранилища.
Чтобы свести к минимуму влияние кэширования страниц, был выполнен шаг инициализации, на котором pgbench запускался перед запуском фактического теста. Результаты этого начального запуска не использовались ни в каком анализе. Это гарантировало, что любые общие страницы, которые можно кэшировать, уже были доступны для двух тестовых прогонов.
На следующей диаграмме показано, как объем памяти экземпляра уменьшается примерно с 4,88 ГБ до 90 МБ при открытии этих 1000 подключений.
Как объяснялось в предыдущем посте этой серии, несмотря на то, что эти соединения простаивали, они потребляли ресурсы памяти и ЦП. Результаты показывают, что эти незанятые соединения влияют на производительность.
Тест скорости транзакций №1: стандартный pgbench
В первом тесте pgbench работал в стандартной конфигурации со 100 клиентскими подключениями. Следующий код является результатом этого запуска pgbench:
тип транзакции: <встроенный: TPC-B (вроде)> коэффициент масштабирования: 1000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 749572 средняя задержка = 80,058 мс tps = 1249. 096708 (включая установление соединений) tps = 1249.116996 (без учета установления соединений)
При 1000 незанятых подключений результат изменился на следующий:
тип транзакции: <встроенный: TPC-B (вроде)> коэффициент масштабирования: 1000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 684434 средняя задержка = 87,686 мс tps = 1140.430155 (включая установление соединений) tps = 1140.449899 (без учета установления соединений)
Результаты показывают, что скорость транзакций снизилась с 1 249 до 1 140 транзакций в секунду. Это падение скорости транзакций на 8,7% из-за незанятых соединений.
Тест скорости транзакций № 2: pgbench только для выбора
Поскольку память, потребляемая бездействующими подключениями, уменьшает объем памяти, доступной для кэша страниц, ожидалось, что влияние этих бездействующих подключений будет более очевидным на запросы чтения. Чтобы проверить это, я запустил pgbench с конфигурацией -S
, которая запускает встроенный скрипт только для выбора для бенчмаркинга. Следующий вывод является результатом этого тестового прогона:
тип транзакции: <встроенный: только выбор> коэффициент масштабирования: 1000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 1181937 средняя задержка = 50,778 мс tps = 1969.344251 (включая установление соединений) tps = 1969.377751 (без учета установления соединений)
При 1000 незанятых подключений результат изменился на следующий:
тип транзакции: <встроенный: только выбор> коэффициент масштабирования: 1000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 966656 средняя задержка = 62,095 мс tps = 1610.440842 (включая установление соединений) tps = 1610. 470585 (без учета установления соединений)
Результаты показывают, что скорость транзакций снизилась с 1969 до 1610 транзакций в секунду (падение на 18,2%).
Тест скорости транзакций № 3: Пользовательский pgbench
Чтобы увидеть влияние этих простаивающих подключений на рабочую нагрузку с интенсивным чтением, я выполнил еще один тест с пользовательским запросом pgbench, который считывал большое количество строк. Следующий код является содержимым пользовательского сценария pgbench, запущенного с использованием pgbench:
\set nbranches :масштаб \set naccounts 100000 * :масштаб \ установить случайную помощь (1, :naccounts) \установить случайную ставку(1, :nbranches) НАЧИНАТЬ; SELECT * FROM pgbench_accounts ГДЕ помощь >= :помощь И помощь < (:помощь + 5000) И ставка=:ставка LIMIT 1; КОНЕЦ;
Каждая транзакция этого пользовательского скрипта pgbench считывает 5000 строк из таблицы pgbench_accounts
и возвращает только одну из этих строк. Идея в том, чтобы каждая транзакция читала больше страниц.
Запуск pgbench с пользовательским скриптом и без каких-либо незанятых подключений показывает следующий результат:
тип транзакции: pgbench_script.sql коэффициент масштабирования: 5000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 227484 средняя задержка = 264,140 мс tps = 378,586790 (включая установление соединений) tps = 378,592772 (без учета установления соединений)
При наличии 1000 незанятых подключений, выполняющих запросы к информационной схеме, результат изменился на следующий:
тип транзакции: pgbench_script.sql коэффициент масштабирования: 5000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 124114 средняя задержка = 484,485 мс tps = 206.404854 (включая установление соединений) tps = 206,507645 (без учета установления соединений)
Результаты показывают, что скорость транзакций снизилась с 378 до 206 транзакций в секунду (падение на 46%).
Вы можете использовать Amazon RDS Performance Insights для просмотра сведений о событиях ожидания механизма во время двух запусков pgbench. На следующем рисунке показано, что большая часть времени была потрачена на событие ожидания DataFileRead
в обоих запусках. Во втором запуске с 1000 незанятых подключений почти все время занимает это событие ожидания. DataFileRead 9Событие 0022 указывает на ожидание чтения из файла данных отношения.
На следующей диаграмме показан показатель пропускной способности чтения Amazon CloudWatch для двух запусков pgbench.
Во время первого запуска скорость чтения составляла около 87 МБ/с, тогда как при втором запуске с 1000 открытых подключений скорость чтения увеличилась примерно до 117 МБ/с. Это произошло из-за того, что бездействующие соединения потребляли свободную память ОС, что приводило к уменьшению кэша ОС. Из-за этого с диска приходилось извлекать больше страниц, а не читать из кеша ОС. Поскольку чтение с диска выполняется намного медленнее, чем чтение из памяти, это приводит к снижению производительности запросов.
пулы соединений
Пулы соединенийпомогают свести к минимуму влияние соединений с базой данных, поддерживая пул соединений, который может совместно использоваться всеми клиентскими соединениями. Вы можете использовать пул соединений приложений, который является частью кода вашего приложения, или независимый пул соединений, например pgbouncer или Amazon RDS Proxy. Эти пулы соединений помогают ограничить количество соединений, которые вы можете открыть, а также повторно использовать соединения, чтобы для каждого нового клиентского соединения не требовалось открывать новое соединение с базой данных. В следующих разделах приведены дополнительные сведения о pgbouncer и прокси-сервере RDS.
pgbouncer
pgbouncer — это облегченный пул соединений, поддерживающий следующие три режима:
- Режим сеанса — Каждое соединение приложения привязано к одному соединению с базой данных. Если соединение переходит в состояние ожидания, pgbouncer не может повторно использовать его для соединений с другими приложениями.
- Режим транзакции — pgbouncer может повторно использовать открытое соединение, как только соединение с приложением завершит транзакцию.
- Режим оператора — соединение можно повторно использовать для других клиентов, как только будет выполнено одно выражение SQL.
В большинстве приложений использование пула в режиме транзакций дает наилучшие результаты. Чтобы проверить преимущества пулов соединений, я установил pgbouncer на сервер, на котором работает pgbench. pgbouncer был настроен на разрешение до 5000 клиентских подключений, но открывал максимум 200 подключений к нашему тестовому экземпляру RDS PostgreSQL. Затем pgbench был запущен для этого пула pgbouncer.
Следующий код является результатом теста пользовательского запуска pgbench с помощью pgbouncer:
тип транзакции: pgbench_script. sql коэффициент масштабирования: 5000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 227064 средняя задержка = 264,600 мс tps = 377,928241 (включая установление соединений) tps = 377,928476 (без учета установления соединений)
Во время выполнения pgbench вы можете просмотреть пул pgbouncer, чтобы увидеть статус соединений:
pgbouncer=# показать пулы; -[ ЗАПИСЬ 1 ]----------- база данных | pgbench пользователь | постгрес кл_актив | 100 cl_waiting | 0 sv_active | 100 sv_idle | 0 sv_used | 0 sv_tested | 0 sv_логин | 0 максимальное ожидание | 0 maxwait_us | 0 режим пула | транзакция
Этот вывод состояния пула показывает, что имеется 100 клиентских подключений ( cl_active
), что приводит к 100 активным подключениям к серверу ( sv_active
).
Во время второго тестового прогона я открыл 1000 подключений и оставил их в состоянии ожидания. Пулеру не нужно было поддерживать какие-либо соединения с сервером для этих бездействующих клиентских соединений. Следующая статистика пула показывает, что существует 1000 клиентских подключений, но есть только одно свободное соединение с PostgreSQL:
.pgbouncer=# показать пулы; -[ ЗАПИСЬ 1 ]----------- база данных | pgbench пользователь | постгрес кл_актив | 1000 cl_waiting | 0 sv_active | 0 sv_idle | 1 sv_used | 0 sv_tested | 0 sv_логин | 0 максимальное ожидание | 0 maxwait_us | 0 режим пула | транзакция
Пулы соединений имеют разные параметры для управления их поведением. Дополнительные сведения см. в разделе Конфигурация pgbouncer.
Когда эти 1000 незанятых клиентских подключений все еще открыты, запуск pgbench с использованием pgbouncer приводит к следующему:
тип транзакции: pgbench_script.sql коэффициент масштабирования: 5000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 226827 средняя задержка = 264,935 мс tps = 377,451418 (включая установление соединений) tps = 377,451655 (без учета установления соединений)
Это показывает, что использование пула подключений не влияет на производительность с 1000 неактивных подключений или без них. Pgbouncer показывает следующий статус во время выполнения pgbench:
pgbouncer=# показать пулы; -[ ЗАПИСЬ 1 ]----------- база данных | pgbench пользователь | постгрес кл_актив | 1100 cl_waiting | 0 sv_active | 100 sv_idle | 0 sv_used | 0 sv_tested | 0 sv_логин | 0 максимальное ожидание | 0 maxwait_us | 0 режим пула | транзакция
Всего имеется 1100 клиентских подключений ( cl_active
), но активно используются только 100 серверных подключений ( sv_active
).
В этом тесте экземпляр RDS имеет только 2 виртуальных ЦП, поэтому 100 параллельных процессов могут привести к большому переключению контекста, что приведет к некоторому снижению производительности. В зависимости от рабочей нагрузки вы можете уменьшить максимальное количество подключений до меньшего. Следующий код является результатом теста с pgbouncer, настроенным на разрешение максимум 20 подключений к базе данных:
тип транзакции: pgbench_script. sql коэффициент масштабирования: 5000 режим запроса: простой количество клиентов: 100 количество потоков: 2 продолжительность: 600 с количество фактически обработанных транзакций: 256267 средняя задержка = 234,286 мс tps = 426,828543 (включая установление соединений) tps = 426.828801 (без установления соединения)
Вы получаете более высокую скорость транзакций с меньшим размером пула соединений. pgbouncer показывает следующий статус во время выполнения pgbench:
pgbouncer=# показать пулы; -[ ЗАПИСЬ 1 ]----------- база данных | pgbench пользователь | постгрес кл_актив | 20 cl_waiting | 80 sv_active | 20 sv_idle | 0 sv_used | 0 sv_tested | 0 sv_логин | 0 максимальное ожидание | 0 maxwait_us | 125884 режим пула | транзакция
В любой момент времени активны только 20 клиентских подключений ( cl_active
). Остальные 80 соединений ( cl_waiting
) ждут своей очереди и получают соединение, как только становится доступным одно из соединений с базой данных. Этот результат показывает, что большее количество подключений не обязательно означает большую пропускную способность. Это меньшее количество подключений к базе данных помогает уменьшить переключение контекста и конкуренцию за ресурсы и, следовательно, повышает общую производительность для этой пользовательской рабочей нагрузки. В целом это верно и для других баз данных.
Прокси-сервер RDS
Как показано в предыдущем разделе, использование пулов подключений может помочь повысить производительность. В зависимости от вашей рабочей нагрузки и доступных ресурсов экземпляра повышение производительности может быть значительным, если для обработки большого количества подключений используется пул соединений.
Однако, поскольку все соединения теперь проходят через пул соединений, он может стать единой точкой отказа. Очень важно убедиться, что вы настроили его для высокой доступности. Это может быть непросто. AWS решает эту проблему, предоставляя полностью управляемый высокодоступный прокси-сервер базы данных: RDS Proxy.
RDS Proxy позволяет настроить пул соединений и управлять им всего за несколько кликов. Прокси-сервер RDS позволяет установить максимальное пороговое значение для подключений, которые могут быть открыты для базы данных. Затем все клиентские соединения используют этот пул соединений. Это помогает при бездействующих соединениях и гарантирует, что любой неожиданный скачок количества соединений не ухудшит производительность базы данных.
На следующем рисунке показана статистика использования прокси-сервера RDS для запуска pgbench, который открыл 100 клиентских подключений. В этом тесте прокси-сервер RDS был настроен на разрешение только 1 % от максимального числа подключений, разрешенных базой данных.
В другом тесте перед запуском pgbench было открыто 1000 незанятых соединений. На следующем рисунке показано, что только два подключения к базе данных, которые уже были открыты RDS Proxy, использовались для 1000 новых простаивающих подключений. Когда запускался pgbench, прокси-сервер RDS открывал дополнительные соединения.
Прокси-сервер RDS также позволяет настроить тайм-аут подключения клиента в режиме ожидания. По умолчанию прокси-сервер закрывает любое клиентское соединение, которое не используется в течение 30 минут. Вы можете изменить этот параметр в соответствии с требованиями вашей рабочей нагрузки. Дополнительные сведения см. в разделе Создание прокси-сервера RDS.
Резюме
Результаты в этом посте показывают, что большее количество подключений к базе данных не означает более высокую пропускную способность. По мере увеличения числа подключений к базе данных также увеличивается переключение контекста и конкуренция за ресурсы, что влияет на производительность.
В сообщении также показано, что соединения PostgreSQL потребляют ресурсы, даже когда они бездействуют, поэтому распространенное предположение о том, что бездействующие соединения не влияют на производительность, неверно.
Если ваше приложение разработано таким образом, что это приводит к большому количеству подключений, независимо от того, активны они или простаивают, вам следует подумать о внесении изменений, чтобы ваша память и ресурсы ЦП не тратились впустую только на управление этими подключениями. Изменение может быть в приложении, так что оно ограничивает количество подключений, или решение может заключаться в использовании пула подключений. Вы можете рассмотреть возможность использования pgbouncer или воспользоваться RDS Proxy, управляемой службой, позволяющей настроить пул соединений несколькими щелчками мыши.
Об авторе
Ясер Раджа — старший консультант группы профессиональных услуг в Amazon Web Services. Вместе с клиентами он создает масштабируемые, высокодоступные и безопасные решения в облаке AWS. Его областью интересов является гомогенная и гетерогенная миграция локальных баз данных в AWS RDS и Aurora PostgreSQL.
Iron Horse Fund: Эффективность фонда
Фонд Rational Iron Horse, класс A | $8,20 | $0,00 | 0,00% | -8,36% | -0,12% | 1,49% | -7,85 % | 2,68% | -8,88% | 0,04% | 2,71% |
S&P 500 ИНДЕКС ОБЩЕЙ ДОХОДНОСТИ Класс | 14280,42 | -92,88 | -0,65% | 0,71% | 7,08% | 12,93% | -0,79% | 12,35% | 7,51% | 10,73% | 11,98% |
Фонд Rational Iron Horse, класс I | 8,21 долл. США | 0,00 долл. США | 0,00% | -8,29% | -0,24% | 90 228 1,36%-7,87% | 3,77% | -8,74% | 0,27 % | 3,82% | |
S&P 500 ИНДЕКС ОБЩЕЙ ДОХОДНОСТИ Класс | 14280,42 | -92,88 | -0,65% | 0,71% | 7,08% | 12,93% | -0,79% | 13,96% | 7,51% | 10,73% | 13,59% |
Фонд Rational Iron Horse, класс C | 8,14 долл. США | 0,00 долл. США | 0,00% | -8,74% | -0,25% | 90 228 1,12%-8,23% | -2,38% | -9,30% | Н/Д | -2,36% | |
S&P 500 ИНДЕКС ОБЩЕЙ ДОХОДНОСТИ Класс | 14280,42 | -92,88 | -0,65% | 0,71% | 7,08% | 12,93% | -0,79% | 12,07% | 7,51% | 10,73% | 11,05% |
(1) | Представляет процентное увеличение/уменьшение стоимости чистых активов по сравнению с предыдущим торговый день. |
(2) | Показатели за период менее одного года не пересчитываются в годовом исчислении. |
(3) | Дата создания фонда Iron Horse Fund класса A — 7 июля 2011 г., а класса I — 16 ноября 2011 г. |
(4) | Максимальная комиссия за продажу акций класса А составляет 5,75%. Инвесторы в акции класса А могут иметь право на снижение комиссионных сборов. |
Коэффициент общих операционных расходов фонда Iron Horse Fund класса A os 1,97% и класса Я составляет 1,72%. Инвестиционный консультант Фонда по договору согласился отказаться от своих платы за управление и/или осуществлять платежи для ограничения расходов Фонда до 31 июля 2012 г. таким образом, чтобы общие годовые операционные расходы (исключая любые налоги, проценты, брокерские комиссии, расходы, понесенные в связи с любым слиянием или реорганизацией, косвенные расходы, расходы других инвестиционных компаний, в которых Фонд может инвестиции или чрезвычайные расходы, такие как судебные тяжбы) Фонда, не превышают 1,95% для акций класса А и 1,70% для акций класса I, при условии возможной окупаемости из Фонда в последующие годы. Пожалуйста, ознакомьтесь с проспектом Фонда для получения более подробной информации. об отказе от расходов.
Приведенные здесь данные о производительности представляют собой прошлые показатели. Текущее представление может быть ниже или выше приведенных выше данных о производительности. Возврат инвестиций и основная стоимость будет колебаться, так что акции при погашении могут стоить больше или меньше их первоначальной стоимости. Прошлые результаты не являются гарантией будущего Результаты.