Início / user-279386

L. Connell's questions

Martin Hope
L. Connell
Asked: 2024-07-09 23:03:35 +0800 CST
  • 5

Eu tenho uma tabela com cerca de 1 milhão de linhas que está sendo tentada para ser lida por um programa Java por meio da interface TQL (ou seja, usando apenas a API Java normal, sem SQL). Mas quando tento ler o contêiner, encontro um erro de memória:

Exception in thread "main" com.toshiba.mwcloud.gs.common.GSStatementException: [1043:CM_MEMORY_LIMIT_EXCEEDED] Memory limit exceeded (name=transactionWork.workerStack, requestedSize=67108880, totalSizeLimit=134217728, freeSizeLimit=1048576, totalSize=74448896, freeSize=0) (address=172.18.0.2:10001, partitionId=29)

a solução óbvia é aumentar o storeMemoryLimit e, portanto, aumentei-o do padrão de 1.024 MB para o dobro, em 2.048 MB. Embora eu tenha aumentado o limite de memória, estou recebendo o mesmo erro ao ser lido no programa Java, pois os valores de totalSizeLimit etc permanecem os mesmos, o que significa que aumentar ainda mais o storeMemoryLimit não ajudaria neste caso (embora eu tenha tentado ).

Também mudei o método de compactação de NONE para o novo ZSTD na esperança de que ele pudesse compactar o conjunto de dados pequeno o suficiente para ser lido de uma vez sem atingir o limite de memória, mas isso também falhou.

Minha única outra idéia é mudar de TQL para SQL e aumentar o limite de memória SQL, mas prefiro não mudar todo o meu código.

Alguma idéia de como ler esta tabela inteira de uma só vez?

griddb
Martin Hope
L. Connell
Asked: 2024-06-22 04:28:37 +0800 CST
  • 6

Eu tenho um programa Java que grava linhas na minha tabela GridDB por meio da API NoSQL. Estou detectando erros corretamente e vejo nos logs que os dados estão sendo armazenados em meu contêiner via multiput, mas quando entro na CLI para visualizar o conteúdo dos dados, o contêiner está completamente vazio?

Primeiro, esta é a aparência do contêiner:

gs[public]> showcontainer LOG_agent_intrusion_exploit
Database    : public
Name        : LOG_agent_intrusion_exploit
Type        : COLLECTION
Partition ID: 22
DataAffinity: -
Partitioned : true
Partition Type           : INTERVAL
Partition Column         : timestamp
Partition Interval Value : 30
Partition Interval Unit  : DAY
Expiration Type      : PARTITION
Expiration Time      : 30
Expiration Time Unit : DAY

Columns:
No  Name                  Type            CSTR  RowKey
------------------------------------------------------------------------------
 0  timestamp             TIMESTAMP(3)    NN
 1  username              STRING
 2  incomingIP            STRING
 3  serverIP              STRING
 4  mtu                   INTEGER
 5  statusCode            INTEGER
 6  cacheHit              STRING
 7  method                STRING
 8  url                   STRING
 9  urlPrefix             STRING
10  urlSuffix             STRING
11  httpVersion           STRING
12  service               STRING
13  riskLevel             STRING
14  headerContentType     STRING
15  bytesReceived         INTEGER
16  bytesSent             INTEGER
17  headerAgent           STRING
18  url2                  STRING
19  url2Prefix            STRING
20  url2Suffix            STRING
21  meta1                 STRING
22  meta2                 STRING
23  meta3                 STRING
24  meta4                 STRING

Meu analisador de log está criando um hashmap com os nomes dos contêineres como nome da chave, reunindo todas as linhas e, em seguida, usando store.multiPut para enviar para o GridDB. para esta função, estou fazendo um bloco try/catch simples que normalmente captura os erros do GridDB.

Trecho rápido:

                for (RawLog log : logs) {
                    try {
                        System.out.println(log.logtype + "~~~~~~");
                        System.out.println("configs.get(log.logtype)" + configs.get(log.logtype));
                        Row row = lp.patternMatcher(proc_container, log, configs.get(log.logtype));
                        if (row != null) {
                            proc_logs.add(row);
                            System.out.println("parsing this row: " + row);
                        } else
                            System.out.println("Could not parse " + log);
                    } catch (Exception e) {
                        e.printStackTrace();
                        System.out.println("Could not parse " + log);
                    }
                }

                containerRowsMap.put(proc_container, proc_logs);

            }
            try {
                db.store.multiPut(containerRowsMap);
            } catch (Exception e) {
                System.out.println("Error with inserting data");
                e.printStackTrace();
            }

Portanto, neste caso, parece que os dados deveriam estar na minha tabela, mas quando executo uma consulta simples select * from LOG_agent_intrusion_exploit;, recebo zero linhas de volta.

Tentei abandonar o multiput e inserir uma linha por vez, mas obtive exatamente o mesmo comportamento.

griddb