ideawu/ssdb

正常运行的ssdb,突然出现只能读取,不可写入的问题,然后过了一会也不能读取了

perrornet opened this issue · 7 comments

报错:./var/data/3548640.ldb: Bad file descriptor
配置文件:

work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 6379
        # bind to public ip
        #ip: 0.0.0.0
        # format: allow|deny: all|ip_prefix
        # multiple allows or denys is supported
        #deny: all
        #allow: 127.0.0.1
        #allow: 192.168
        # auth password must be at least 32 characters
        #auth: very-strong-password
        #readonly: yes
        # in ms, to log slowlog with WARN level
        #slowlog_timeout: 5

replication:
        binlog: yes
        # Limit sync speed to *MB/s, -1: no limit
        sync_speed: -1
        slaveof:
                # to identify a master even if it moved(ip, port changed)
                # if set to empty or not defined, ip: 0.0.0.0
                #id: svc_2
                # sync|mirror, default is sync
                #type: sync
                #host: localhost
                #port: 8889

logger:
        level: error
        output: ssdb.log.txt
        rotate:
                size: 100000

leveldb:
        # in MB
        cache_size: 1024
        # in MB
        write_buffer_size: 1024
        # in MB/s
        compaction_speed: 1000
        # yes|no
        compression: yes

错误截图:
image

磁盘io:
image

可能是磁盘满或者磁盘损坏.

是数据损坏了, 我在使用python代码 leveldb.RepairDB("./var/data")恢复了leveldb数据后, 可以启动,但是在读取数据时,占用内存太大了
机器是8G的内存,启动10秒后内存迅速的攀升,直到被操作系统kill掉.
image
这是配置文件:
image
已经降到很低了

下载最新的 ssdb 代码, 用 ssdb 自带的 tool/repair 工具修复一次试试.

运行了repair工具,但是一直卡在compacting data这里几个小时了,还没有任何输出,为啥这里这么耗时了?我的数据也才200多G

我这里也是,ssdb-repair之后,启动一直卡在compacting

请问问题解决了吗

I have the same problem with data compaction. Can't stop compaction. And now have very poor degraded performance.
Help me please!