@@ -469,7 +469,9 @@ Jobs will run on your own Runners in parallel only if:
...
@@ -469,7 +469,9 @@ Jobs will run on your own Runners in parallel only if:
### `only`/`except` (basic)
### `only`/`except` (basic)
NOTE: **Note:**
NOTE: **Note:**
These parameters will soon be [deprecated](https://gitlab.com/gitlab-org/gitlab/issues/27449) in favor of [`rules`](#rules) as it offers a more powerful syntax.
The [`rules`](#rules) syntax is now the preferred method of setting job policies.
`only` and `except` are [candidates for deprecation](https://gitlab.com/gitlab-org/gitlab/issues/27449),
and may be removed in the future.
`only` and `except` are two parameters that set a job policy to limit when
`only` and `except` are two parameters that set a job policy to limit when
@@ -273,7 +273,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
...
@@ -273,7 +273,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
decrease in indexing time. We'll enable them when indexing is done. This step is optional!
decrease in indexing time. We'll enable them when indexing is done. This step is optional!
```bash
```bash
curl --request PUT localhost:9200/gitlab-production/_settings --data'{
curl --request PUT localhost:9200/gitlab-production/_settings --header'Content-Type: application/json'--data'{
"index" : {
"index" : {
"refresh_interval" : "-1",
"refresh_interval" : "-1",
"number_of_replicas" : 0
"number_of_replicas" : 0
...
@@ -355,7 +355,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
...
@@ -355,7 +355,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
1. Enable replication and refreshing again after indexing (only if you previously disabled it):
1. Enable replication and refreshing again after indexing (only if you previously disabled it):
```bash
```bash
curl --request PUT localhost:9200/gitlab-production/_settings --data'{
curl --request PUT localhost:9200/gitlab-production/_settings --header'Content-Type: application/json'---data'{
"index" : {
"index" : {
"number_of_replicas" : 1,
"number_of_replicas" : 1,
"refresh_interval" : "1s"
"refresh_interval" : "1s"
...
@@ -367,7 +367,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
...
@@ -367,7 +367,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
For Elasticsearch 6.x, the index should be in read-only mode before proceeding with the force merge:
For Elasticsearch 6.x, the index should be in read-only mode before proceeding with the force merge:
```bash
```bash
curl --request PUT localhost:9200/gitlab-production/_settings --data'{
curl --request PUT localhost:9200/gitlab-production/_settings ---header'Content-Type: application/json'--data'{
"settings": {
"settings": {
"index.blocks.write": true
"index.blocks.write": true
} }'
} }'
...
@@ -376,13 +376,13 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
...
@@ -376,13 +376,13 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
Then, initiate the force merge:
Then, initiate the force merge:
```bash
```bash
curl --request POST 'http://localhost:9200/gitlab-production/_forcemerge?max_num_segments=5'
curl --request POST 'localhost:9200/gitlab-production/_forcemerge?max_num_segments=5'
```
```
After this, if your index is in read-only mode, switch back to read-write:
After this, if your index is in read-only mode, switch back to read-write:
```bash
```bash
curl --request PUT localhost:9200/gitlab-production/_settings --data'{
curl --request PUT localhost:9200/gitlab-production/_settings ---header'Content-Type: application/json'--data'{
"settings": {
"settings": {
"index.blocks.write": false
"index.blocks.write": false
} }'
} }'
...
@@ -470,7 +470,7 @@ However, some larger installations may wish to tune the merge policy settings:
...
@@ -470,7 +470,7 @@ However, some larger installations may wish to tune the merge policy settings:
- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently.
- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently.
```bash
```bash
curl --request PUT http://localhost:9200/gitlab-production/_settings--data'{
curl --request PUT localhost:9200/gitlab-production/_settings ---header'Content-Type: application/json'--data'{
"index" : {
"index" : {
"merge.policy.max_merged_segment": "2gb"
"merge.policy.max_merged_segment": "2gb"
}
}
...
@@ -480,7 +480,7 @@ However, some larger installations may wish to tune the merge policy settings:
...
@@ -480,7 +480,7 @@ However, some larger installations may wish to tune the merge policy settings:
- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs.
- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs.
```bash
```bash
curl --request PUT http://localhost:9200/gitlab-production/_settings--data'{
curl --request PUT localhost:9200/gitlab-production/_settings ---header'Content-Type: application/json'--data'{