Frequently Asked Questions¶
Common questions about Nebula Graph and more.
- Frequently Asked Questions
- Trouble Shooting
- graphd Config File Doesn't Register to Meta Server
- Errors Thrown When Inserting Data After Tag or Edge is Created
- Errors Thrown When Executing Command in Docker
- How to Check Logs
- How to Check Configs
- How to Check Runtime Configs
- Connection Refused
- Process Crash
- Could not create logging file:... Too many open files
- Storaged Service Cannot Start Normally
- How to Check Nebula Graph Version
- Modifying the Configuration File Does not Take Effect
- Modify RocksDB block cache
- General Information
- Trouble Shooting
Trouble Shooting session lists the common operation errors in Nebula Graph.
graphd Config File Doesn't Register to Meta Server¶
When starting Nebula Graph services with the
storaged processes start too fast to make the graphd config file registered into the meta server. The same problem may also occur when restarting.
If you are using the beta version, start the metad service first, then the storaged and graphd to avoid such problem. We will resolve this problem in the next release.
Start metad first:
nebula> scripts/nebula.service start metad [INFO] Starting nebula-metad... [INFO] Done
Then start storaged and graphd
nebula> scripts/nebula.service start storaged [INFO] Starting nebula-storaged... [INFO] Done nebula> scripts/nebula.service start graphd [INFO] Starting nebula-graphd... [INFO] Done
Errors Thrown When Inserting Data After Tag or Edge is Created¶
This is likely caused by setting the
heartbeat_interval_secs value to fetch data from the meta server. Conduct the following steps to resolve:
If meta has registered, check
heartbeat_interval_secs value in console with the following command.
nebula> GET CONFIGS storage:heartbeat_interval_secs nebula> GET CONFIGS graph:heartbeat_interval_secs
If the value is large, change it to 1s with the following command.
nebula> UPDATE CONFIGS storage:heartbeat_interval_secs=1 nebula> UPDATE CONFIGS graph:heartbeat_interval_secs=1
Note the changes take effect in the next period.
Errors Thrown When Executing Command in Docker¶
This is likely caused by the inconsistency between the docker IP and the default listening address (172.17.0.2). Thus we need to change the the latter.
- First run
ifconfigin container to check your container IP, here we assume your IP is 172.17.0.3.
- In directory
/usr/local/nebula/etc, check the config locations of all the IP addresses with the command
grep "172.17.0.2" . -r.
- Change all the IPs you find in step 2 to your container IP 172.17.0.3.
- Restart all the services.
How to Check Logs¶
Logs are stored under
/usr/local/nebula/logs/ by default.
For details of logs, please refer to logs.
How to Check Configs¶
Configuration files are stored under
/usr/local/nebula/etc/ by default.
How to Check Runtime Configs¶
In Nebula console, run
nebula> SHOW CONFIGS;
For configuration details, please see here.
E1121 04:49:34.563858 256 GraphClient.cpp:54] Thrift rpc call failed: AsyncSocketException: connect failed, type = Socket not open, errno = 111 (Connection refused): Connection refused
Check service status by
$ /usr/local/nebula/scripts/nebula.service status all
- Check disk space
- Check memory usage
Could not create logging file:... Too many open files¶
- Check your disk space
- Check log directory
- reset your max open files by
ulimit -n 65536
Storaged Service Cannot Start Normally¶
When the same host is used for single host or cluster test, the storaged service cannot start normally. The listening port of the storaged service is red in the console.
Check the logs of the storaged service. If you find the "wrong cluster" error message, the possible cause is that the cluster id generated by Nebula Graph during the single host test and the cluster test are inconsistent. You need to delete the cluster.id file and the data directory and restart the service.
How to Check Nebula Graph Version¶
Use the command
curl http://ip:port/status to obtain the git_info_sha, the commitID of the binary package.
Modifying the Configuration File Does not Take Effect¶
Nebula Graph uses the following two methods obtaining configurations:
- From the configuration files (You need to modify the files then restart the services);
- From the Meta. Set via CLI and persists in Meta service. Please refer to the Configs Syntax for details.
Modifying the configuration file does not take effect because Nebula Graph gets configuration in the second method (from meta) by default. If you want to use the first way, please add the
--local_config=true option in flag files
graphd.conf (flag files directory is
Modify RocksDB block cache¶
Modify the storage layer's configuration file
storaged.conf (the default directory is
/usr/local/nebula/etc/, yours maybe different) and restart the service. For example:
# Change rocksdb_block_cache to 1024 MB --rocksdb_block_cache = 1024 # Stop storaged and restart /usr/local/nebula/scripts/nebula.service stop storaged /usr/local/nebula/scripts/nebula.service start storaged
curl 127.0.0.1:12000/get_flags | grep rocksdb_block_cache in your command line to confirm your modification.
$ curl 127.0.0.1:12000/get_flags | grep rocksdb_block_cache % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3041 100 3041 0 0 989k 0 --:--:-- --:--:-- --:--:-- 989k rocksdb_block_cache=1024
General Information lists the conceptual questions about Nebula Graph.
Explanations on the Time Return in Queries¶
nebula> GO FROM 101 OVER follow =============== | follow._dst | =============== | 100 | --------------- | 102 | --------------- | 125 | --------------- Got 3 rows (Time spent: 7431/10406 us)
Taking the above query as an example, the number
7431 in Time spent is the time spent by the database itself, that is, the time it takes for the query engine to receive a query from the console, fetch the data from the storage and perform a series of calculation ; the number
10406 is the time spent from the client's perspective, that is, the time it takes for the console from sending a request and receiving a response to displaying the result on the screen.