Skip to content

Commit fc9ac78

Browse files
committed
PR fixes debugging insights and troubleshooting
1 parent 145827f commit fc9ac78

File tree

2 files changed

+4
-4
lines changed

2 files changed

+4
-4
lines changed

docs/tips-and-tricks/debugging-insights.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -86,7 +86,7 @@ ORDER BY count() DESC;
8686

8787
### Disk space problems {#disk-space-problems}
8888

89-
Disk space exhaustion in replicated setups creates cascading problems. When one node runs out of space, other nodes continue trying to sync with it, causing network traffic spikes and confusing symptoms. One community member spent 4 hours debugging what was simply low disk space.
89+
Disk space exhaustion in replicated setups creates cascading problems. When one node runs out of space, other nodes continue trying to sync with it, causing network traffic spikes and confusing symptoms. One community member spent 4 hours debugging what was simply low disk space. Check out this [query](/knowledgebase/useful-queries-for-troubleshooting#show-disk-storage-number-of-parts-number-of-rows-in-systemparts-and-marks-across-databases) to monitor your disk storage on a particular cluster.
9090

9191
AWS users should be aware that default general purpose EBS volumes have a 16TB limit.
9292

@@ -102,15 +102,15 @@ Small frequent inserts create performance problems. The community has identified
102102

103103
[Official recommendation](/best-practices/selecting-an-insert-strategy#batch-inserts-if-synchronous): minimum 1,000 rows per insert, ideally 10,000 to 100,000.
104104

105-
### Data quality issues {#data-quality-issues}
105+
### Invalid timestamps issues {#data-quality-issues}
106106

107107
Applications that send data with arbitrary timestamps create partition problems. This leads to partitions with data from unrealistic dates (like 1998 or 2050), causing unexpected storage behavior.
108108

109109
### `ALTER` operation risks {#alter-operation-risks}
110110

111111
Large `ALTER` operations on multi-terabyte tables can consume significant resources and potentially lock databases. One community example involved changing an Integer to a Float on 14TB of data, which locked the entire database and required rebuilding from backups.
112112

113-
**Prevention:**
113+
**Monitor expensive mutations:**
114114

115115
```sql
116116
SELECT database, table, mutation_id, command, parts_to_do, is_done

docs/troubleshooting/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -145,7 +145,7 @@ Initial installation, server configuration, database creation, data ingestion is
145145
If you can't find a solution:
146146

147147
1. **Ask AI** - <KapaLink>Ask AI</KapaLink> for instant answers.
148-
1. **Check system tables** - Run `SELECT * FROM system.processes` and `SELECT * FROM system.query_log ORDER BY event_time DESC LIMIT 10`
148+
1. **Check system tables** - [Overview](/operations/system-tables/overview)
149149
2. **Review server logs** - Look for error messages in your ClickHouse logs
150150
3. **Ask the community** - [Join Our Community Slack](https://clickhouse.com/slack), [GitHub Discussions](https://github.com/ClickHouse/ClickHouse/discussions)
151151
4. **Get professional support** - [ClickHouse Cloud support](https://clickhouse.com/support)

0 commit comments

Comments
 (0)