You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/fundamentals/config-files.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,11 +3,10 @@ title: Config files
3
3
description: How to configure geth using config files
4
4
---
5
5
6
-
There are many flags and commands that can be provided to Geth on startup to influence how your node will behave. It is often convenient to configure these options in a file rather than typing them out on the command line every time you start your node. This can be done using a simple shell script to start Geth.
6
+
There are many flags and commands that can be provided to Geth on startup to influence how your node will behave. It is often convenient to configure these options in a file rather than typing them out on the command line every time you start your node. This can be done using a simple shell script to start Geth.
7
7
8
8
There are also other configuration options that are not accessible from the command line but can be adjusted by providing Geth with a config file. This gives access to lower level configuration that influences how some of Geth's internal components behave.
9
9
10
-
11
10
## Shell scripts
12
11
13
12
The benefit of writing a shell script for starting a Geth node is that it is more easily repeatable and you don't have to remember lots of syntax for making a node behave in a certain way. This is especially useful for running multiple nodes with their own specific configurations.
Copy file name to clipboardExpand all lines: docs/fundamentals/databases.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,6 @@ If Geth stops unexpectedly the database can be corrupted. This is known as an "u
53
53
54
54
If an unexpected shutdown does occur, the `removedb` subcommand can be used to delete the state database and resync it from the ancient database. This should get the database back up and running.
55
55
56
-
57
56
## Pebble
58
57
59
58
It is possible to configure Geth to use [Pebble](https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/) instead of LevelDB for recent data. The main reason to include the alternative database is that the Go implementation of LevelDB is not actively maintained; Pebble is an actively maintained replacement that should offer a better long term option. There is no urgent reason to switch the database type yet - LevelDB works well and Pebble is still being evaluated for potentially replacing LevelDB as the default option some time in the future. However, if you wish to experiment with running Geth with Pebble, add the following flag to your Geth startup commands:
@@ -62,4 +61,4 @@ It is possible to configure Geth to use [Pebble](https://www.cockroachlabs.com/b
62
61
--db.engine=pebble
63
62
```
64
63
65
-
This also requires resyncing from scratch in a fresh data directory, because if an existing LevelDB database is detected on startup, Geth will default to using that, overriding the `--db.engine=pebble` flag. Pebble only works on 64 bit systems.
64
+
This also requires resyncing from scratch in a fresh data directory, because if an existing LevelDB database is detected on startup, Geth will default to using that, overriding the `--db.engine=pebble` flag. Pebble only works on 64 bit systems.
Copy file name to clipboardExpand all lines: docs/interacting-with-geth/rpc/batch.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,8 @@ title: Batch requests
3
3
description: How to make batch requests using JSON-RPC API
4
4
---
5
5
6
-
The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects.
7
-
6
+
The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects.
7
+
8
8
Below is an example for fetching a list of blocks in JS:
9
9
10
10
```js
@@ -38,10 +38,10 @@ main()
38
38
.catch(err=>console.log(err));
39
39
```
40
40
41
-
In this case there's no dependency between the requests. Often the retrieved data from one request is needed to issue a second one. Let's take the example of fetching all the receipts for a range of blocks. The JSON-RPC API provides `eth_getTransactionReceipt` which takes in a transaction hash and returns the corresponding receipt object, but no method to fetch receipt objects for a whole block. We need to get the list of transactions in a block and then call `eth_getTransactionReceipt` for each of them.
42
-
41
+
In this case there's no dependency between the requests. Often the retrieved data from one request is needed to issue a second one. Let's take the example of fetching all the receipts for a range of blocks. The JSON-RPC API provides `eth_getTransactionReceipt` which takes in a transaction hash and returns the corresponding receipt object, but no method to fetch receipt objects for a whole block. We need to get the list of transactions in a block and then call `eth_getTransactionReceipt` for each of them.
42
+
43
43
We can break this into 2 batch requests:
44
-
44
+
45
45
- First to download the list of transaction hashes for all of the blocks in our desired range
46
46
- And then to download the list of receipts objects for all of the transaction hashes
Copy file name to clipboardExpand all lines: docs/interacting-with-geth/rpc/ns-personal.md
-3Lines changed: 0 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,6 @@ title: personal Namespace
3
3
description: Documentation for the JSON-RPC API "personal" namespace
4
4
---
5
5
6
-
7
6
The JSON-RPC API's `personal` namespace has historically been used to manage accounts and sign transactions and data over RPC. However, it has **now been deprecated** in favour of using [Clef](/docs/tools/clef/introduction) as an external signer and account manager. One of the major changes is moving away from indiscriminate locking and unlocking of accounts and instead using Clef to explicitly approve or deny specific actions. The first section on this page shows the suggested replacement for each method in `personal`. The second section shows the deprecated methods for archival purposes.
8
7
9
8
## Method replacements
@@ -225,8 +224,6 @@ Unpair deletes a pairing between some specific types of smartcard wallet and Get
225
224
226
225
InitializeWallet is for initializing some specific types of smartcard wallet at a provided URL. There is not yet a corresponding method in Clef.
227
226
228
-
229
-
230
227
## Deprecated method documentation
231
228
232
229
The personal API managed private keys in the key store. It is now deprecated in favour of using [Clef](/docs/tools/clef/introduction) for interacting with accounts. The following documentation should be treated as archive information and users should migrate to using Clef for account interactions.
Copy file name to clipboardExpand all lines: docs/interacting-with-geth/rpc/pubsub.md
-3Lines changed: 0 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,11 +34,8 @@ to cancel the subscription:
34
34
## Considerations {#considerations}
35
35
36
36
1. Notifications are sent for current events and not for past events. For use cases that cannot afford to miss any notifications, subscriptions are probably not the best option.
37
-
38
37
2. Subscriptions require a full duplex connection. Geth offers such connections in the form of WebSocket and IPC (enabled by default).
39
-
40
38
3. Subscriptions are coupled to a connection. If the connection is closed all subscriptions that are created over this connection are removed.
41
-
42
39
4. Notifications are stored in an internal buffer and sent from this buffer to the client. If the client is unable to keep up and the number of buffered notifications reaches a limit (currently 10k) the connection is closed. Keep in mind that subscribing to some events can cause a flood of notifications, e.g. listening for all logs/blocks when the node starts to synchronize.
Memory tracks the amount of RAM being used by Geth. Three metrics are plotted: the cache size, i.e. the total RAM reserved for Geth (default 1024 MB) is plotted as `held`; the amount of the cache actually being used by Geth is plotted as `used`; the number of bytes being allocated by the system per second is plotted as `alloc`.
32
+
Memory tracks the amount of RAM being used by Geth. Three metrics are plotted: the cache size, i.e. the total RAM reserved for Geth (default 1024 MB) is plotted as `held`; the amount of the cache actually being used by Geth is plotted as `used`; the number of bytes being allocated by the system per second is plotted as `alloc`.
33
33
34
34
#### Disk
35
35
@@ -39,7 +39,7 @@ Disk tracks the rate that data is written to (plotted as `write`) or read from (
39
39
40
40
#### Goroutines
41
41
42
-
Tracks the total number of active goroutines being used by Geth. Goroutines are lighweight threads managed by the Go runtime, they allow processes to
42
+
Tracks the total number of active goroutines being used by Geth. Goroutines are lighweight threads managed by the Go runtime, they allow processes to
@@ -105,7 +105,7 @@ Geth has a capacity for pending transactions defined by `--txpool.globalslots` (
105
105
The block processing panel tracks the time taken to complete the various tasks involved in processing each block, measured in microseconds or nanoseconds. Specifically, this includes:
106
106
107
107
-**execution**: time taken to execute the transactions in the block
108
-
-**validation**: time taken to validate that the information in a received block body matches what is described in the block header.
108
+
-**validation**: time taken to validate that the information in a received block body matches what is described in the block header.
109
109
-**commit**: time taken to write the new block to the chain data
110
110
-**account read**: time taken to access account information from the state trie
111
111
-**account update**: time taken to incorporate dirty account objects into the state trie (account trie)
@@ -142,7 +142,6 @@ The transaction processing panel tracks the time taken to complete the various t
142
142
143
143
#### Block propagation
144
144
145
-
146
145
<Note>
147
146
Block propagation was disabled in Geth at The Merge. Block propagation is now the responsibility of the consensus client. Included here for archival interest.
148
147
</Note>
@@ -156,15 +155,14 @@ Block propagation metrics track the rate that the local node hears about, receiv
156
155
-**known broadcasts**: counts all blocks that have been broadcast by peers including those that are too far behind the head to be downloaded.
157
156
-**malicious broadcasts**: the number of blocks which are determined to be malicious per second
158
157
159
-
160
158
#### Transaction propagation
161
159
162
160
Transaction propagation tracks the sending and receiving of transactions on the peer-to-peer network. This includes:
163
161
164
162
-**ingress announcements**: inbound announcements (notifications of a transaction's availability) per second
165
163
-**known announcements**: announcements that are ignored because the local node is already aware of them, per second
166
-
-**underpriced announcements**: announcements per second that do not get fetched because they pay too little gas
167
-
-**malicious announcements**: announcements per second that are dropped because they appear malicious
164
+
-**underpriced announcements**: announcements per second that do not get fetched because they pay too little gas
165
+
-**malicious announcements**: announcements per second that are dropped because they appear malicious
168
166
-**ingress broadcasts**: number of transactions propagated from peers per second
169
167
-**known broadcasts**: transactions per second that are ignored because they duplicate transactions that the local node already knows about
170
168
-**underpriced broadcasts**: all fetched transactions that are dropped due to paying insufficient gas, per second
@@ -181,7 +179,7 @@ Transaction propagation tracks the sending and receiving of transactions on the
181
179
182
180
#### Block forwarding
183
181
184
-
The block forwarding panel counts the announcements and the blocks that the local node receives that it should pass on to its peers.
182
+
The block forwarding panel counts the announcements and the blocks that the local node receives that it should pass on to its peers.
185
183
186
184
#### Transaction fetcher peers
187
185
@@ -209,10 +207,10 @@ measures the rate that data is written to, or read from, the levelDB and ancient
209
207
-**ancient write**: Rate that data is written to the freezer (the database storing older data)
210
208
-**compaction read**: Rate that data is written to the levelDb database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
211
209
-**compaction write**: Rate that data is read from to the levelDB database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
212
-
210
+
213
211
#### Session totals
214
212
215
-
Instead of the *rate* that data is read from, and written to, the levelDB and ancients databases (as per `Data rate`), this panel tracks the total amount of data read and written across the entire time Geth is running.
213
+
Instead of the _rate_ that data is read from, and written to, the levelDB and ancients databases (as per `Data rate`), this panel tracks the total amount of data read and written across the entire time Geth is running.
216
214
217
215
#### Persistent size
218
216
@@ -226,7 +224,6 @@ These panels show the amount of time spent compacting the levelDB database, dura
226
224
The current default Geth Grafana dashboard includes panels for light nodes. Light nodes are not currently functional since Ethereum moved to proof-of-stake.
227
225
</Note>
228
226
229
-
230
227
## Creating new dashboards
231
228
232
229
If the default dashboard isn't right for you, you can update it in the browser. Remove panels by clicking on their titles and selectign `remove`. Add a new panel by clicking the "plus" icon in the upper right of the browser window. There, you will have to define an InfluxDB query for the metric you want to display. The endpoints for the various metrics that Geth reports are listed by Geth at the address/port combination passed to `--metrics.addr` and `metrics.port` on startup - by default `127.0.0.1:6060/debug/metrics`. It is also possible to configure a panel by providing a JSON configuration model. Individial components are defined using the following syntax (the example below is for the CPU panel):
@@ -294,9 +291,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
294
291
"format": "time_series",
295
292
"groupBy": [
296
293
{
297
-
"params": [
298
-
"$interval"
299
-
],
294
+
"params": ["$interval"],
300
295
"type": "time"
301
296
}
302
297
],
@@ -310,9 +305,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
310
305
"select": [
311
306
[
312
307
{
313
-
"params": [
314
-
"value"
315
-
],
308
+
"params": ["value"],
316
309
"type": "field"
317
310
},
318
311
{
@@ -339,9 +332,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
339
332
"format": "time_series",
340
333
"groupBy": [
341
334
{
342
-
"params": [
343
-
"$interval"
344
-
],
335
+
"params": ["$interval"],
345
336
"type": "time"
346
337
}
347
338
],
@@ -355,9 +346,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
355
346
"select": [
356
347
[
357
348
{
358
-
"params": [
359
-
"value"
360
-
],
349
+
"params": ["value"],
361
350
"type": "field"
362
351
},
363
352
{
@@ -384,9 +373,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
384
373
"format": "time_series",
385
374
"groupBy": [
386
375
{
387
-
"params": [
388
-
"$interval"
389
-
],
376
+
"params": ["$interval"],
390
377
"type": "time"
391
378
}
392
379
],
@@ -400,9 +387,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
0 commit comments