Oracle mechanics

02.06.2012

Операции LOAD TABLE CONVENTIONAL / LOAD AS SELECT: direct-path и другие способы вставки в 11.2

Filed under: direct-path DML,Oracle,PX,statistics,wait events — Игорь Усольцев @ 00:10
Tags: , , , ,

Попробовал оценить насколько|почему хорошо работает direct-path insert (операция LOAD AS SELECT в плане выполнения), а поскольку нет смысла описывать эту операцию отдельно от традиционной (conventional) вставки — сделал несколько простых тестов различных вариантов вставки массивов строк в DML типа INSERT…SELECT…:

  • традиционная непараллельная вставка — conventional insert
  • традиционная параллельная — conventional parallel insert
  • прямая непараллельная — direct-path serial insert
  • прямая непараллельная вставка с параллельным выполнением запроса — direct-path serial insert + parallel SELECT execution
  • прямая параллельная — direct-path parallel insert

Попутно выяснилась интересная техническая особенность выполнения прямых вставок, судя по которой разработчики Oracle намеренно отдали предпочтение последнему варианту — direct-path parallel insert, и проверил влияние параметра _direct_path_insert_features на режим прямой вставки в версии 11.2

Тестовая схема:

11.2.0.3.@SQL> create table T1 as select rownum n1 from dual connect by rownum <= 10000000;

Table created.

SQL> select bytes, blocks from dba_segments where segment_name = 'T1';

BYTES     BLOCKS
---------- ----------
125829120       7680 -- объём исходной таблицы / вставляемых данных ~ 120 MB

SQL> exec dbms_stats.gather_table_stats('','T1');

PL/SQL procedure successfully completed.

SQL> create table T2 as select * from T1 where 1=0;

Table created.

1) традиционная непараллельная вставка

SQL> insert into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:03.50

----------------------------------------------------------------------------------
| Id  | Operation                | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |
----------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |      |        |       |  2912 (100)|          |
|   1 |  LOAD TABLE CONVENTIONAL |      |        |       |            |          |
|   2 |   TABLE ACCESS FULL      | T1   |     10M|    57M|  2912   (2)| 00:00:01 |
----------------------------------------------------------------------------------

Статистика выполнения:

Time Model

STAT_NAME                                                               DELTA
---------------------------------------------------------------- ------------
DB time                                                               3485342
sql execute elapsed time                                              3485167
DB CPU                                                                3371488

Counted Statistics

NAME                                                                    DELTA
---------------------------------------------------------------- ------------
logical read bytes from cache                                      2124021760
redo size                                                           161738756
undo change vector size                                              23234736
...
session logical reads                                                  129640
db block changes                                                       128627
db block gets                                                          107669
db block gets from cache                                               107669
redo entries                                                            80459
Heap Segment Array Inserts                                              46587
HSC Heap Segment Block Changes                                          46587
consistent gets                                                         21971
consistent gets from cache                                              21971
...
table scan blocks gotten                                                 7604
no work - consistent read gets                                           7604
...
redo buffer allocation retries                                              6
...

Wait Events

NAME                                                                    WAITS      TIME_MS     TIMEOUTS AVG_WAIT_MS
---------------------------------------------------------------- ------------ ------------ ------------ -----------
SQL*Net message from client                                                 1        51961            0     51961,5
SQL*Net message to client                                                   1            0            0           0

— объём проделанной работы огромен — logical read bytes from cache ~ 2 GB при вставке 120 MB данных, никаких ожиданий, все операции с блоками данных+undo+redo в памяти отражены в DB CPU, которое составляет большую часть затраченного на выполнение времени DB time

2) традиционная параллельная вставка

Интересная идея: параллельный DML с отключённой direct-pathRandolf Geist. Parallel DML — Conventional (non-direct-path) Inserts As Select

SQL> alter session enable parallel dml;

Session altered.

SQL> -- согласно документации NOAPPEND отключает режим прямой вставки:
SQL> insert/*+ NOAPPEND PARALLEL*/ into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:02.21

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT           |          |        |       |  1616 (100)|          |        |      |            |
|   1 |  PX COORDINATOR            |          |        |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)      | :TQ10000 |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    LOAD TABLE CONVENTIONAL |          |        |       |            |          |  Q1,00 | PCWP |            | -- параллельное выполнение!
|   4 |     PX BLOCK ITERATOR      |          |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL     | T1       |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------

Automatic Degree of Parallelism Information:
--------------------------------------------

- Degree of Parallelism of 2 is derived from scan of object SCOTT.T1

Note
-----
- automatic DOP: Computed Degree of Parallelism is 2

— операция LOAD TABLE CONVENTIONAL выполняется параллельно — Parallel execution Combined With Parent (PCWP) в отличие от первого случая

До завершения транзакции можно наблюдать традиционные рудименты параллельного DML:

SQL> select count(*) from T2;
select count(*) from T2
*
ERROR at line 1:
ORA-12838: cannot read/modify an object after modifying it in parallel

Кроме того, до момента завершения транзакции остаются активными 2 параллельные сессии, участвовавшие в операции:

SQL> select count(distinct sid) from v$px_session where qcsid = sys_context('userenv','sid') and sid <> qcsid;

COUNT(DISTINCTSID)
------------------
2

, что позволяет получить суммарные статистики/ожидания и основной сессии (Query Coordinator — QC), и PX-процессов:

Time Model

STAT_NAME                                                               DELTA
---------------------------------------------------------------- ------------
DB time                                                               4300692
sql execute elapsed time                                              4293874
DB CPU                                                                3801422

Counted Statistics

NAME                                                                    DELTA
---------------------------------------------------------------- ------------
logical read bytes from cache                                      2085519360
session pga memory max                                             1097359616
redo size                                                           161126864
undo change vector size                                              23227224
...
DML statements parallelized                                                 1 -- статистика подтверждает факт параллельного выполнения
...

Wait Events

NAME                                                                    WAITS      TIME_MS     TIMEOUTS AVG_WAIT_MS
---------------------------------------------------------------- ------------ ------------ ------------ -----------
PX Deq: Execute Reply                                                      28         2103            0        75,1
events in waitclass Other                                                   4           93            0        23,4
PX Deq: Join ACK                                                            2            3            0         1,4
PX Deq: Parse Reply                                                         2            1            0         0,4
PX Deq Credit: send blkd                                                    2            0            0         0,1

— несмотря на значительно меньшее время выполнения INSERT в таком параллельном режиме, ресурсов DB time / DB CPU суммарно было потрачено больше, чем в непараллельном режиме №1

В таблице транзакций V$TRANSACTION отражены 3 пользовательские параллельные транзакции (PTX=’YES’) с одинаковым идентификатором родительской транзакциии PTX_XID, указывающим на XID сессии sqlplus.exe — координатора запроса:

SQL> select to_char(s.SID) as sid,
2         s.PROGRAM,
3         s.TYPE,
4         s.PDML_STATUS,
5         t.START_TIME as TX_START_TIME,
6         t.STATUS,
7         t.XID,
8         t.PTX,
9         t.PTX_XID,
10         t.USED_UBLK,
11         t.LOG_IO,
12         t.CR_GET
13    from v$session s, v$transaction t
14   where s.sid in (select sid
15                     from v$px_session
16                    where qcsid = sys_context('userenv', 'sid')
17                    )
18     and s.TADDR = t.ADDR
19  /

SID    PROGRAM         TYPE       PDML_STA TX_START_TIME        STATUS  XID              PTX PTX_XID           USED_UBLK     LOG_IO     CR_GET
------ --------------- ---------- -------- -------------------- ------- ---------------- --- ---------------- ---------- ---------- ----------
827    oracle@ (P000)  USER       ENABLED  05/31/12 17:56:06    ACTIVE  1F001000080B0000 YES 0D001300990A0000        729     113025      11408
677    sqlplus.exe     USER       ENABLED  05/31/12 17:56:06    ACTIVE  0D001300990A0000 YES 0D001300990A0000          1         11         45
49     oracle@ (P001)  USER       ENABLED  05/31/12 17:56:06    ACTIVE  17000C00880A0000 YES 0D001300990A0000        728     113322      11399

— значение V$TRANSACTION.LOG_IO для параллельных процессов (P00X) в точности соответствует сумме V$SESS_IO.BLOCK_GETS + V$SESS_IO.BLOCK_CHANGES:

SQL> select to_char(si.SID) as sid,
2         s.PROGRAM,
3         si.CONSISTENT_GETS,
4         si.BLOCK_GETS,
5         si.BLOCK_CHANGES,
6         (si.BLOCK_GETS + si.BLOCK_CHANGES) as "BLOCK_GETS+BLOCK_CHANGES"
7    from v$sess_io si, v$session s
8   where si.sid in (select sid
9                      from v$px_session
10                     where qcsid = sys_context('userenv', 'sid'))
11     and si.SID = s.SID
12  /

SID    PROGRAM         CONSISTENT_GETS BLOCK_GETS BLOCK_CHANGES BLOCK_GETS+BLOCK_CHANGES
------ --------------- --------------- ---------- ------------- ------------------------
49     oracle@ (P001)            11399      52385         60937           113322
677    sqlplus.exe                 180         99            87              186
827    oracle@ (P000)            11408      52086         60939           113025

3) прямая НЕпараллельная вставка

SQL> insert/*+ APPEND */ into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:04.20

-------------------------------------------------------------------------------------------------------
| Id  | Operation          | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |  OMem |  1Mem | Used-Mem |
-------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT   |      |        |       |  2912 (100)|          |       |       |          |
|   1 |  LOAD AS SELECT    |      |        |       |            |          |   529K|   529K|  529K (0)| -- непараллельная операция
|   2 |   TABLE ACCESS FULL| T1   |     10M|    57M|  2912   (2)| 00:00:01 |       |       |          |
-------------------------------------------------------------------------------------------------------

Time Model

STAT_NAME                                                               DELTA
---------------------------------------------------------------- ------------
DB time                                                               4194187
sql execute elapsed time                                              4194074
DB CPU                                                                2139675

Counted Statistics

NAME                                                                    DELTA
---------------------------------------------------------------- ------------
logical read bytes from cache                                       124387328
physical write bytes                                                123469824
physical write total bytes                                          123469824
table scan rows gotten                                               10000000
redo size                                                               25284
redo size for direct writes                                             24632
session logical reads                                                   15128
db block gets                                                            7581
consistent gets from cache (fastpath)                                    7547
consistent gets                                                          7547
consistent gets from cache                                               7547
no work - consistent read gets                                           7536
physical writes                                                          7536
physical writes non checkpoint                                           7536
physical writes direct                                                   7536
table scan blocks gotten                                                 7536
db block gets direct                                                     7536
redo entries                                                              475
...
physical write IO requests                                                472
...
undo change vector size                                                   212
...

Wait Events

NAME                                                                    WAITS      TIME_MS     TIMEOUTS AVG_WAIT_MS
---------------------------------------------------------------- ------------ ------------ ------------ -----------
direct path write                                                         256         2054            0           8

— интересный результат: операции с кэшем (logical read bytes from cacheredo size, undo change vector size) сократились на порядки, соответственно потребление DB CPU уменьшилось в полтора раза по сравнению с conventional insert (№1), но у сессии появились ожидания ввода-вывода direct path write суммарной длительностью ~ 2 секунд. В результате этот вариант direct-path serial insert оказался самым медленным, и чуть ниже станет понятно почему

4) прямая непараллельная вставка с параллельным выполнением запроса

SQL> insert/*+ APPEND PARALLEL*/ into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:05.13

----------------------------------------------------------------------------------------------------------------
| Id  | Operation             | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT      |          |        |       |  1616 (100)|          |        |      |            |
|   1 |  LOAD AS SELECT       |          |        |       |            |          |        |      |            | -- непараллельная операция вставки
|   2 |   PX COORDINATOR      |          |        |       |            |          |        |      |            | -- при параллельном выполнении запроса
|   3 |    PX SEND QC (RANDOM)| :TQ10000 |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   4 |     PX BLOCK ITERATOR |          |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL| T1       |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------

Automatic Degree of Parallelism Information:
--------------------------------------------

- Degree of Parallelism of 2 is derived from scan of object SCOTT.T1

Note
-----
- automatic DOP: Computed Degree of Parallelism is 2

Time Model

STAT_NAME                                                               DELTA
---------------------------------------------------------------- ------------
DB time                                                               5095282
sql execute elapsed time                                              5092829
DB CPU                                                                2852567

Wait Events

NAME                                                                    WAITS      TIME_MS     TIMEOUTS AVG_WAIT_MS
---------------------------------------------------------------- ------------ ------------ ------------ -----------
direct path write                                                         259         2180            0         8,4
log file sync                                                               1           41            0        41,1
events in waitclass Other                                                   7            1            0         0,1

— аналогично предыдущему, немного хуже по времени выполнения, но дешевле по стоимости в плане выполнения, т.к. стоимость DML целиком состоит из стоимости запроса

5) прямая параллельная вставка

SQL> alter session enable parallel dml;

Session altered.

SQL> insert/*+ APPEND PARALLEL*/ into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:01.44

----------------------------------------------------------------------------------------------------------------
| Id  | Operation             | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT      |          |        |       |  1616 (100)|          |        |      |            |
|   1 |  PX COORDINATOR       |          |        |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM) | :TQ10000 |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    LOAD AS SELECT     |          |        |       |            |          |  Q1,00 | PCWP |            | -- параллельное выполнение LOAD AS SELECT
|   4 |     PX BLOCK ITERATOR |          |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL| T1       |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------

Automatic Degree of Parallelism Information:
--------------------------------------------

- Degree of Parallelism of 2 is derived from scan of object SCOTT.T1

Note
-----
- automatic DOP: Computed Degree of Parallelism is 2

Time Model
STAT_NAME                                                               DELTA
---------------------------------------------------------------- ------------
DB time                                                               2752155
sql execute elapsed time                                              2744822
DB CPU                                                                2289652

Counted Statistics
NAME                                                                    DELTA
---------------------------------------------------------------- ------------
logical read bytes from cache                                       136740864
physical write bytes                                                123469824
physical write total bytes                                          123469824
table scan rows gotten                                               10000000
...
consistent gets from cache                                               7858
consistent gets                                                          7858
...
db block gets direct                                                     7536
physical writes direct                                                   7536
...
physical writes                                                          7536
...
redo size                                                                7260
...
DB time                                                                   423
undo change vector size                                                   372
...
CPU used by this session                                                  228
...
physical write total IO requests                                          119
physical write IO requests                                                119
physical write total multi block requests                                 118
...
user I/O wait time                                                         39
...
DML statements parallelized                                                 1
...

Wait Events
NAME                                                                    WAITS      TIME_MS     TIMEOUTS AVG_WAIT_MS
---------------------------------------------------------------- ------------ ------------ ------------ -----------
PX Deq: Execute Reply                                                      28         1375            0        49,1
direct path write                                                          45          401            0         8,9 -- here be dragons
events in waitclass Other                                                   4           50            0        12,5
PX Deq: Join ACK                                                            2            3            0         1,5
PX Deq: Parse Reply                                                         2            1            0         0,5
PX Deq Credit: send blkd                                                    2            0            0         0,1

Очень быстро, почти на треть выгоднее по суммарным (QC+PX)  затратам DB Time по сравнению с традиционным conventional insert (вариант №1)

Суммарная статистика выглядит отлично, однако смущает уменьшившееся в 5 раз суммарное время, затраченное PX-процессами на прямой ввод-вывод и отражённое в ожиданиях direct path write: так при непараллельном direct-path insert (варианты №№ 3,4) ожидания direct path write занимали ~ 2 секунд против 400 мс при параллельном. И хотя из описания WAITEVENT: «direct path write» Reference Note [ID 50416.1] понятно, особенно доверять цифрам этого ожидания не стоит:

Hence this wait event is very misleading as:

  • The total number of waits does not reflect the number of IO requests
  • The total time spent in «direct path write» does not always reflect the true wait time

— пятикратная разница представляется слишком большой!

Причина различий хорошо видна при сравнении SQL трейсов с ожиданиями (уровень 8) непараллельного ora_16636 и параллельного p001_24721 выполнениий:

$ grep 'direct path write' ORCL112_ora_16636.trc
WAIT #140515660335584: nam='direct path write' ela= 19153 file number=4 first dba=1068992 block cnt=16 obj#=-1 tim=1338397662865217
WAIT #140515660335584: nam='direct path write' ela= 34580 file number=4 first dba=1069264 block cnt=16 obj#=-1 tim=1338397663065325
WAIT #140515660335584: nam='direct path write' ela= 35190 file number=4 first dba=1069344 block cnt=16 obj#=-1 tim=1338397663153036
WAIT #140515660335584: nam='direct path write' ela= 34412 file number=4 first dba=1069424 block cnt=16 obj#=-1 tim=1338397663240155
WAIT #140515660335584: nam='direct path write' ela= 6716 file number=4 first dba=1069552 block cnt=16 obj#=-1 tim=1338397663325337
WAIT #140515660335584: nam='direct path write' ela= 1804 file number=4 first dba=1069744 block cnt=16 obj#=-1 tim=1338397663448540
...
$ grep 'direct path write' ORCL112_p001_24721.trc
WAIT #139909108847552: nam='direct path write' ela= 15585 file number=4 first dba=1846424 block cnt=64 obj#=-1 tim=1338407610731370
WAIT #139909108847552: nam='direct path write' ela= 21058 file number=4 first dba=2078620 block cnt=64 obj#=-1 tim=1338407610933850
WAIT #139909108847552: nam='direct path write' ela= 27348 file number=4 first dba=2079452 block cnt=64 obj#=-1 tim=1338407611199020
WAIT #139909108847552: nam='direct path write' ela= 21981 file number=4 first dba=2080220 block cnt=64 obj#=-1 tim=1338407611447666
WAIT #139909108847552: nam='direct path write' ela= 18170 file number=4 first dba=2081244 block cnt=64 obj#=-1 tim=1338407611765803

— для последовательной прямой вставки Oracle использует  «db file multiblock write count» = 16 (асинхронная запись по 256KB), а при параллельной пишет по 64 блока (1MB) — что выглядит крайне нелогично, но, вероятно, разработчики механизма прямой записи ориентировались именно на параллельное выполнение direct-path DML операций

Попутно проверил, влияет ли параметр _direct_path_insert_features на режим прямой вставки:

11.2.0.3.@SQL> select NAME, VALUE, ISDEFAULT from v$ses_optimizer_env where sid = sys_context('userenv','sid') and name = 'parallel_dml_mode';

NAME                                     VALUE                     ISD
---------------------------------------- ------------------------- ---
parallel_dml_mode                        enabled                   NO

SQL> @param_ _direct_path_insert_features

NAME                                       VALUE  IS_DEF   DSC
------------------------------------------ ------ -------- -----------------------------------
_direct_path_insert_features               0      TRUE     disable direct path insert features

SQL> alter session set "_direct_path_insert_features" = 1;

Session altered.

SQL> insert/*+ APPEND PARALLEL*/ into T2 select * from T1;

10000000 rows created.

Elapsed: 00:00:01.40
----------------------------------------------------------------------------------------------------------------
| Id  | Operation             | Name     | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------------------
|   0 | INSERT STATEMENT      |          |        |       |  1616 (100)|          |        |      |            |
|   1 |  PX COORDINATOR       |          |        |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM) | :TQ10000 |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    LOAD AS SELECT     |          |        |       |            |          |  Q1,00 | PCWP |            | -- по-прежнему параллельное выполнение
|   4 |     PX BLOCK ITERATOR |          |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL| T1       |     10M|    57M|  1616   (2)| 00:00:01 |  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------------------

Automatic Degree of Parallelism Information:
--------------------------------------------

- Degree of Parallelism of 2 is derived from scan of object SCOTT.T1

Note
-----
- automatic DOP: Computed Degree of Parallelism is 2

— в версии 11.2 модификация параметра _direct_path_insert_features не отключает режим прямой вставки (либо влияет каким-то более сложным образом)

4 комментария »

  1. А есть ли смысл тестировать параллелизм на 120Мб таблице?
    Смысл примерно такой же, как сравнивать ружьё и пушку для стрельбы по воробьям.
    Было бы интересно увидеть тест на 5Гб таблице (да, пусть она вся лежит в кэше, чтобы тестировать именно вставку).

    Не раскрыта тема IO: неясно сколько и каких дисков выделено.
    Не раскрыта тема файловой системы, где лежат файлы данных.

    Было бы интересно увидеть vmstat/iostat в течение теста

    комментарий от Vladimir Sitnikov — 02.06.2012 @ 00:31 | Ответить

    • >>Было бы интересно увидеть тест на 5Гб таблице
      Протестируйте если интересно, Владимир, не сочтите за труд. По моему мнению принципиально отличаться могут только результаты тестов непараллельной вставки с параллельным выполнением запроса

      >>Не раскрыта тема файловой системы
      подсистема ввода вывода для этих тестов не имеет большого значения — т.к. операция записи direct path write кусками по 1 МБ, скорее всего, будет выполняться быстрее, чем по 256 КБ для любой неперегруженной дисковой подсистемы — легко проверить на ноутбуке, например
      А файловая система у Oracle одна — ASM

      комментарий от Igor Usoltsev — 02.06.2012 @ 00:59 | Ответить

  2. Благодарю за тест кейс и подробное описание проделанных экспериментов. На данный момент сея проблема стала очень актуальной.

    комментарий от Jurij — 08.08.2014 @ 08:43 | Ответить

    • успехов в решении!

      комментарий от Игорь Усольцев — 09.08.2014 @ 22:23 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: