[MDEV-8687] CREATE TEMPORARY TABLE vs plain SELECT causes 280x perf drop: InnoDB takes unneeded locks - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Critical
Resolution: Not a Bug
Affects Version/s: 10.0(EOL), 10.1(EOL)
Fix Version/s: N/A
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Labels:
- innodb
Environment:
ppc64el

Sprint:
10.0.22

Description

With the attached SQL and psdoit script to run queries concurrently, you can see that the CREATE TEMPORARY TABLE part of the query causes concurrency to tank. The related issue of ~~MDEV-8684~~ is for problems in the InnoDB mutex code, while this bug is for the fact that InnoDB is down in lock_rec_convert_impl_to_exp() when it probably shouldn't be.

It appears that CREATE TEMPORARY TABLE is triggering InnoDB to go and do a whole bunch of locking that it doesn't do when you just run a plain SELECT.

The addition of CREATE TEMPORARY TABLE makes performance 280x worse.

 # mysql -u root < sql

 # time ./psdoit 1

 0.022s

 # time ./psdoit 10

 0.112s

 # time ./psdoit 100

 7.150s

 # time ./psdoit 200

 30.422s

 # time ./psdoit 400

 190.378s

Things get very bad, very fast. We spend almost all our time in a locking
food fight:

     37.42%  mysqld         mysqld              [.] ut_delay(unsigned long)

		    ---ut_delay(unsigned long)

		       |--99.74%-- mutex_spin_wait(void*, bool, char const*, unsigned long)

		       |          |

		       |          |--74.70%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone .constprop.71]

		       |          |          lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const*)

		       |          |          lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const

		       |          |          sel_set_rec_lock(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const*, unsigned long, unsigned long,

		       |          |          row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long)

		       |          |          |

		       |          |          |--76.07%-- ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function)

		       |          |          |          handler::index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)

		       |          |          |          handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)

		       |          |          |          join_read_key2(THD*, st_join_table*, TABLE*, st_table_ref*)

		       |          |          |          sub_select(JOIN*, st_join_table*, bool)

		       |          |          |

and:

     27.96%  mysqld         [kernel.kallsyms]   [k] _raw_spin_lock

		    ---_raw_spin_lock

		       |--58.11%-- futex_wait_setup

		       |          |

		       |          |--99.96%-- 0

		       |          |          futex_wait

		       |          |          do_futex

		       |          |          sys_futex

		       |          |          system_call

		       |          |          |

		       |          |          |--64.91%-- __lll_lock_wait

		       |          |          |          |

		       |          |          |          |--83.30%-- pthread_mutex_lock

		       |          |          |          |          |

		       |          |          |          |          |--52.72%-- os_event_reset(os_event*)

		       |          |          |          |          |          sync_array_reserve_cell(sync_array_t*, void*, unsigned long, char const*, unsigned long, unsi

		       |          |          |          |          |          mutex_spin_wait(void*, bool, char const*, unsigned long)

		       |          |          |          |          |          |

		       |          |          |          |          |          |--75.08%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone .constprop.7

		       |          |          |          |          |          |          lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*, dict_index

		       |          |          |          |          |          |          lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*, unsigned cha

		       |          |          |          |          |          |          sel_set_rec_lock(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned

		       |          |          |          |          |          |          row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

sql
314 kB
2015-08-28 01:00
psdoit
0.6 kB
2015-08-28 01:00

Issue Links

relates to

MDEV-8684 UT_RELAX_CPU isn't at all relaxing

Closed

Activity

Ascending order - Click to sort in descending order

Stewart Smith created issue - 2015-08-28 01:04

Stewart Smith made changes - 2015-08-28 01:04

Field	Original Value	New Value
Link		This issue relates to ~~MDEV-8684~~ [ ~~MDEV-8684~~ ]

Stewart Smith made changes - 2015-08-28 01:06

Description

With the attached SQL and psdoit script to run queries concurrently, you can see that the CREATE TEMPORARY TABLE part of the query causes concurrency to *tank*. The related issue of ~~MDEV-8684~~ is for problems in the InnoDB mutex code, while this bug is for the fact that InnoDB is down in lock_rec_convert_impl_to_exp() when it probably shouldn't be.

It appears that CREATE TEMPORARY TABLE is triggering InnoDB to go and do a whole bunch of locking that it doesn't do when you just run a plain SELECT.

The addition of CREATE TEMPORARY TABLE makes performance 280x worse.

{{
# mysql -u root < sql

# time ./psdoit 1
0.022s

# time ./psdoit 10
0.112s

# time ./psdoit 100
7.150s

# time ./psdoit 200
30.422s

# time ./psdoit 400
190.378s

Things get very bad, very fast. We spend almost all our time in a locking
food fight:

37.42% mysqld mysqld [.] ut_delay(unsigned long)
|
---ut_delay(unsigned long)
|
|--99.74%-- mutex_spin_wait(void*, bool, char const*,
unsigned long)
| |
| |--74.70%--
pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone
.constprop.71]
| |
lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned long const*)
| |
lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*,
unsigned char const*, dict_index_t*, unsigned long const
| | sel_set_rec_lock(buf_block_t
const*, unsigned char const*, dict_index_t*, unsigned long const*, unsigned
long, unsigned long,
| | row_search_for_mysql(unsigned
char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long)
| | |
| | |--76.07%--
ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int,
ha_rkey_function)
| | |
handler::index_read_map(unsigned char*, unsigned char const*, unsigned long,
ha_rkey_function)
| | |
handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned
long, ha_rkey_function)
| | | join_read_key2(THD*,
st_join_table*, TABLE*, st_table_ref*)
| | | sub_select(JOIN*,
st_join_table*, bool)
| | |

and:

27.96% mysqld [kernel.kallsyms] [k] _raw_spin_lock
|
---_raw_spin_lock
|
|--58.11%-- futex_wait_setup
| |
| |--99.96%-- 0
| | futex_wait
| | do_futex
| | sys_futex
| | system_call
| | |
| | |--64.91%-- __lll_lock_wait
| | | |
| | | |--83.30%--
pthread_mutex_lock
| | | | |
| | | | |--52.72%--
os_event_reset(os_event*)
| | | | |
sync_array_reserve_cell(sync_array_t*, void*, unsigned long, char const*,
unsigned long, unsi
| | | | |
mutex_spin_wait(void*, bool, char const*, unsigned long)
| | | | |
|
| | | | |
|--75.08%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long)
[clone .constprop.7
| | | | |
| lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char
const*, dict_index
| | | | |
| lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t
const*, unsigned cha
| | | | |
| sel_set_rec_lock(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned
| | | | |
| row_search_for_mysql(unsigned char*, unsigned long,
row_prebuilt_t*, unsigned long

}}

With the attached SQL and psdoit script to run queries concurrently, you can see that the CREATE TEMPORARY TABLE part of the query causes concurrency to *tank*. The related issue of ~~MDEV-8684~~ is for problems in the InnoDB mutex code, while this bug is for the fact that InnoDB is down in lock_rec_convert_impl_to_exp() when it probably shouldn't be.

It appears that CREATE TEMPORARY TABLE is triggering InnoDB to go and do a whole bunch of locking that it doesn't do when you just run a plain SELECT.

The addition of CREATE TEMPORARY TABLE makes performance 280x worse.

{{ # mysql -u root < sql

# time ./psdoit 1
0.022s

# time ./psdoit 10
0.112s

# time ./psdoit 100
7.150s

# time ./psdoit 200
30.422s

# time ./psdoit 400
190.378s

Things get very bad, very fast. We spend almost all our time in a locking
food fight:

37.42% mysqld mysqld [.] ut_delay(unsigned long)
|
---ut_delay(unsigned long)
|
|--99.74%-- mutex_spin_wait(void*, bool, char const*,
unsigned long)
| |
| |--74.70%--
pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone
.constprop.71]
| |
lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned long const*)
| |
lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*,
unsigned char const*, dict_index_t*, unsigned long const
| | sel_set_rec_lock(buf_block_t
const*, unsigned char const*, dict_index_t*, unsigned long const*, unsigned
long, unsigned long,
| | row_search_for_mysql(unsigned
char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long)
| | |
| | |--76.07%--
ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int,
ha_rkey_function)
| | |
handler::index_read_map(unsigned char*, unsigned char const*, unsigned long,
ha_rkey_function)
| | |
handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned
long, ha_rkey_function)
| | | join_read_key2(THD*,
st_join_table*, TABLE*, st_table_ref*)
| | | sub_select(JOIN*,
st_join_table*, bool)
| | |

and:

27.96% mysqld [kernel.kallsyms] [k] _raw_spin_lock
|
---_raw_spin_lock
|
|--58.11%-- futex_wait_setup
| |
| |--99.96%-- 0
| | futex_wait
| | do_futex
| | sys_futex
| | system_call
| | |
| | |--64.91%-- __lll_lock_wait
| | | |
| | | |--83.30%--
pthread_mutex_lock
| | | | |
| | | | |--52.72%--
os_event_reset(os_event*)
| | | | |
sync_array_reserve_cell(sync_array_t*, void*, unsigned long, char const*,
unsigned long, unsi
| | | | |
mutex_spin_wait(void*, bool, char const*, unsigned long)
| | | | |
|
| | | | |
|--75.08%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long)
[clone .constprop.7
| | | | |
| lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char
const*, dict_index
| | | | |
| lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t
const*, unsigned cha
| | | | |
| sel_set_rec_lock(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned
| | | | |
| row_search_for_mysql(unsigned char*, unsigned long,
row_prebuilt_t*, unsigned long }}

Elena Stepanova made changes - 2015-08-30 00:11

Description

With the attached SQL and psdoit script to run queries concurrently, you can see that the CREATE TEMPORARY TABLE part of the query causes concurrency to *tank*. The related issue of ~~MDEV-8684~~ is for problems in the InnoDB mutex code, while this bug is for the fact that InnoDB is down in lock_rec_convert_impl_to_exp() when it probably shouldn't be.

It appears that CREATE TEMPORARY TABLE is triggering InnoDB to go and do a whole bunch of locking that it doesn't do when you just run a plain SELECT.

The addition of CREATE TEMPORARY TABLE makes performance 280x worse.

{{ # mysql -u root < sql

# time ./psdoit 1
0.022s

# time ./psdoit 10
0.112s

# time ./psdoit 100
7.150s

# time ./psdoit 200
30.422s

# time ./psdoit 400
190.378s

Things get very bad, very fast. We spend almost all our time in a locking
food fight:

37.42% mysqld mysqld [.] ut_delay(unsigned long)
|
---ut_delay(unsigned long)
|
|--99.74%-- mutex_spin_wait(void*, bool, char const*,
unsigned long)
| |
| |--74.70%--
pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone
.constprop.71]
| |
lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned long const*)
| |
lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*,
unsigned char const*, dict_index_t*, unsigned long const
| | sel_set_rec_lock(buf_block_t
const*, unsigned char const*, dict_index_t*, unsigned long const*, unsigned
long, unsigned long,
| | row_search_for_mysql(unsigned
char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long)
| | |
| | |--76.07%--
ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int,
ha_rkey_function)
| | |
handler::index_read_map(unsigned char*, unsigned char const*, unsigned long,
ha_rkey_function)
| | |
handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned
long, ha_rkey_function)
| | | join_read_key2(THD*,
st_join_table*, TABLE*, st_table_ref*)
| | | sub_select(JOIN*,
st_join_table*, bool)
| | |

and:

27.96% mysqld [kernel.kallsyms] [k] _raw_spin_lock
|
---_raw_spin_lock
|
|--58.11%-- futex_wait_setup
| |
| |--99.96%-- 0
| | futex_wait
| | do_futex
| | sys_futex
| | system_call
| | |
| | |--64.91%-- __lll_lock_wait
| | | |
| | | |--83.30%--
pthread_mutex_lock
| | | | |
| | | | |--52.72%--
os_event_reset(os_event*)
| | | | |
sync_array_reserve_cell(sync_array_t*, void*, unsigned long, char const*,
unsigned long, unsi
| | | | |
mutex_spin_wait(void*, bool, char const*, unsigned long)
| | | | |
|
| | | | |
|--75.08%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long)
[clone .constprop.7
| | | | |
| lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char
const*, dict_index
| | | | |
| lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t
const*, unsigned cha
| | | | |
| sel_set_rec_lock(buf_block_t const*, unsigned char const*,
dict_index_t*, unsigned
| | | | |
| row_search_for_mysql(unsigned char*, unsigned long,
row_prebuilt_t*, unsigned long }}

With the attached SQL and psdoit script to run queries concurrently, you can see that the CREATE TEMPORARY TABLE part of the query causes concurrency to *tank*. The related issue of ~~MDEV-8684~~ is for problems in the InnoDB mutex code, while this bug is for the fact that InnoDB is down in lock_rec_convert_impl_to_exp() when it probably shouldn't be.

It appears that CREATE TEMPORARY TABLE is triggering InnoDB to go and do a whole bunch of locking that it doesn't do when you just run a plain SELECT.

The addition of CREATE TEMPORARY TABLE makes performance 280x worse.

{noformat}
# mysql -u root < sql

# time ./psdoit 1
0.022s

# time ./psdoit 10
0.112s

# time ./psdoit 100
7.150s

# time ./psdoit 200
30.422s

# time ./psdoit 400
190.378s
{noformat}

Things get very bad, very fast. We spend almost all our time in a locking
food fight:

{noformat}
37.42% mysqld mysqld [.] ut_delay(unsigned long)
|
---ut_delay(unsigned long)
|
|--99.74%-- mutex_spin_wait(void*, bool, char const*, unsigned long)
| |
| |--74.70%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone .constprop.71]
| | lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const*)
| | lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const
| | sel_set_rec_lock(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned long const*, unsigned long, unsigned long,
| | row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long)
| | |
| | |--76.07%-- ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function)
| | | handler::index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)
| | | handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)
| | | join_read_key2(THD*, st_join_table*, TABLE*, st_table_ref*)
| | | sub_select(JOIN*, st_join_table*, bool)
| | |
{noformat}

and:

{noformat}
27.96% mysqld [kernel.kallsyms] [k] _raw_spin_lock
|
---_raw_spin_lock
|
|--58.11%-- futex_wait_setup
| |
| |--99.96%-- 0
| | futex_wait
| | do_futex
| | sys_futex
| | system_call
| | |
| | |--64.91%-- __lll_lock_wait
| | | |
| | | |--83.30%-- pthread_mutex_lock
| | | | |
| | | | |--52.72%-- os_event_reset(os_event*)
| | | | | sync_array_reserve_cell(sync_array_t*, void*, unsigned long, char const*, unsigned long, unsi
| | | | | mutex_spin_wait(void*, bool, char const*, unsigned long)
| | | | | |
| | | | | |--75.08%-- pfs_mutex_enter_func(ib_mutex_t*, char const*, unsigned long) [clone .constprop.7
| | | | | | lock_rec_convert_impl_to_expl(buf_block_t const*, unsigned char const*, dict_index
| | | | | | lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*, unsigned cha
| | | | | | sel_set_rec_lock(buf_block_t const*, unsigned char const*, dict_index_t*, unsigned
| | | | | | row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long
{noformat}

Stewart Smith added a comment - 2015-08-31 05:02

One possibility as to what's going on is that InnoDB is taking locks as if statement based binary logging is enabled.

I'd argue that in this day and age, it should do so based on mixed mode replication rather than statement based, although I haven't looked at what the default binlog-format is in modern MariaDB (although there's probably a strong case for mixed mode if it isn't already)

Stewart Smith added a comment - 2015-08-31 05:02 One possibility as to what's going on is that InnoDB is taking locks as if statement based binary logging is enabled. I'd argue that in this day and age, it should do so based on mixed mode replication rather than statement based, although I haven't looked at what the default binlog-format is in modern MariaDB (although there's probably a strong case for mixed mode if it isn't already)

Elena Stepanova made changes - 2015-09-01 14:29

Status

Open [ 1 ]

Confirmed [ 10101 ]

Elena Stepanova added a comment - 2015-09-01 14:39

	1	10	100	200	400
MariaDB 5.5.45	0.019	0.084	2.160	14.047	60.398
MySQL 5.5.45	0.022	0.084	1.085	3.891	41.689
MariaDB 10.0.21	0.026	0.097	1.658	20.697	163.562
MySQL 5.6.26	0.043	0.167	1.975	7.036	82.006
MariaDB 10.1.6	0.020	0.075	1.973	27.845	152.873
MySQL 5.7.8	0.043	0.201	2.147	4.043	21.544

Small values are too volatile for meaningful comparison. High values are better on MySQL everywhere, on 5.7 they are quite impressive (but even on 5.6 they are much better than 10.0/10.1).

Elena Stepanova added a comment - 2015-09-01 14:39 1 10 100 200 400 MariaDB 5.5.45 0.019 0.084 2.160 14.047 60.398 MySQL 5.5.45 0.022 0.084 1.085 3.891 41.689 MariaDB 10.0.21 0.026 0.097 1.658 20.697 163.562 MySQL 5.6.26 0.043 0.167 1.975 7.036 82.006 MariaDB 10.1.6 0.020 0.075 1.973 27.845 152.873 MySQL 5.7.8 0.043 0.201 2.147 4.043 21.544 Small values are too volatile for meaningful comparison. High values are better on MySQL everywhere, on 5.7 they are quite impressive (but even on 5.6 they are much better than 10.0/10.1).

Elena Stepanova made changes - 2015-09-01 14:40

Fix Version/s		10.1 [ 16100 ]
Fix Version/s		10.0 [ 16000 ]
Affects Version/s		10.1 [ 16100 ]
Affects Version/s		10.0 [ 16000 ]
Affects Version/s	10.0.17 [ 18300 ]
Assignee		Sergey Vojtovich [ svoj ]

Sergey Vojtovich made changes - 2015-09-08 09:43

Assignee

Sergey Vojtovich [ svoj ]

Jan Lindström [ jplindst ]

Sergey Vojtovich added a comment - 2015-09-08 09:45

jplindst, could you check this? Should we merge fix from MySQL?

Sergey Vojtovich added a comment - 2015-09-08 09:45 jplindst , could you check this? Should we merge fix from MySQL?

Rasmus Johansson (Inactive) made changes - 2015-10-21 10:43

Sprint

10.0.22 [ 17 ]

Rasmus Johansson (Inactive) made changes - 2015-10-21 10:43

Rank

Ranked higher

Jan Lindström (Inactive) made changes - 2015-10-21 12:50

Comment

[ Can you share your my.cnf file, I could not repeat this problem using Linux j35-jan-1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux and log-bin, mixed, innodb-locks-unsafe-for-binlog=0. I used MySQL 5.6.27 and MariaDB 10.0.21 (development version). ]

Jan Lindström (Inactive) added a comment - 2015-10-23 15:20

This is not a bug as default isolation level is REPEATABLE_READ. For plain select we do not need to take row locks, instead a consistent read is enough. But for CREATE [TEMPORARY] TABLE ... SELECT we need to take row locks to maintain selected range consistent also remember that InnoDB does not know is binary log used or not only for innodb-locks-unsafe-for-binlog case is optimized.

Jan Lindström (Inactive) added a comment - 2015-10-23 15:20 This is not a bug as default isolation level is REPEATABLE_READ. For plain select we do not need to take row locks, instead a consistent read is enough. But for CREATE [TEMPORARY] TABLE ... SELECT we need to take row locks to maintain selected range consistent also remember that InnoDB does not know is binary log used or not only for innodb-locks-unsafe-for-binlog case is optimized.

Jan Lindström (Inactive) made changes - 2015-10-23 15:20

Component/s		Storage Engine - XtraDB [ 10135 ]
Fix Version/s		N/A [ 14700 ]
Fix Version/s	10.0 [ 16000 ]
Fix Version/s	10.1 [ 16100 ]
Resolution		Not a Bug [ 6 ]
Status	Confirmed [ 10101 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:41

Workflow

MariaDB v3 [ 71230 ]

MariaDB v4 [ 149523 ]

People

Assignee:: Jan Lindström (Inactive)

Reporter:: Stewart Smith

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2015-08-28 01:04

Updated:: 2015-10-23 15:20

Resolved:: 2015-10-23 15:20

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration