ashtul
commented
2 years ago @tyler-boyd Can you please provide more details for your use case?
Can you please attach the FT.INFO output for the index?
Open tyler-boyd opened 2 years ago
ashtul
commented
2 years ago @tyler-boyd Can you please provide more details for your use case?
Can you please attach the FT.INFO output for the index?
tyler-boyd
commented
2 years ago Our search documents are mostly boring strings/numbers, but the payload is a 1kb+ protobuf binary blob.
We have 2 identical schemas, one for unit tests (with the prefix "unit.") and one for local dev (with the prefix "dev."). Interestingly, the issue doesn't seem to occur when there's only one schema created (eg. I only ran unit tests, or I only ran the dev server). But as soon as I do the other thing, the redis server crashes shortly but not immediately.
Again, as far as I can tell, this only happens under Docker running an amd64 image on an M1 chip (qemu). Our CI systems and my non-M1 coworkers are uanffected by this issue.
ft.info:
1) index_name
2) unit.txrouter.V1.purchases.searchindex2
3) index_options
4) (empty array)
5) index_definition
6) 1) key_type
2) HASH
3) prefixes
4) 1) unit.txrouter.V1.purchases_data
5) default_score
6) "1"
7) payload_field
8) payload
7) attributes
8) 1) 1) identifier
2) sourcePurchaseId
3) attribute
4) sourcePurchaseId
5) type
6) TEXT
7) WEIGHT
8) "1"
2) 1) identifier
2) sourceMessageSequence
3) attribute
4) sourceMessageSequence
5) type
6) NUMERIC
3) 1) identifier
2) totalAmountDue
3) attribute
4) totalAmountDue
5) type
6) NUMERIC
4) 1) identifier
2) arbitration_status
3) attribute
4) arbitration_status
5) type
6) TEXT
7) WEIGHT
8) "1"
5) 1) identifier
2) paymentStatus
3) attribute
4) paymentStatus
5) type
6) TEXT
7) WEIGHT
8) "1"
6) 1) identifier
2) purchaseDate
3) attribute
4) purchaseDate
5) type
6) NUMERIC
7) SORTABLE
7) 1) identifier
2) assurance_status
3) attribute
4) assurance_status
5) type
6) TEXT
7) WEIGHT
8) "1"
8) 1) identifier
2) item_cityStateProvince
3) attribute
4) item_cityStateProvince
5) type
6) TEXT
7) WEIGHT
8) "1"
9) 1) identifier
2) buyer_organization_name
3) attribute
4) buyer_organization_name
5) type
6) TEXT
7) WEIGHT
8) "1"
10) 1) identifier
2) buyer_organization_auctionAccessId
3) attribute
4) buyer_organization_auctionAccessId
5) type
6) TEXT
7) WEIGHT
8) "1"
11) 1) identifier
2) title_status
3) attribute
4) title_status
5) type
6) TEXT
7) WEIGHT
8) "1"
12) 1) identifier
2) region
3) attribute
4) region
5) type
6) TEXT
7) WEIGHT
8) "1"
13) 1) identifier
2) purchaser_name
3) attribute
4) purchaser_name
5) type
6) TEXT
7) WEIGHT
8) "1"
14) 1) identifier
2) purchaser_auctionAccessId
3) attribute
4) purchaser_auctionAccessId
5) type
6) TEXT
7) WEIGHT
8) "1"
15) 1) identifier
2) data_version
3) attribute
4) data_version
5) type
6) TEXT
7) WEIGHT
8) "1"
16) 1) identifier
2) auctionHubId
3) attribute
4) auctionHubId
5) type
6) TEXT
7) WEIGHT
8) "1"
17) 1) identifier
2) auctionHubName
3) attribute
4) auctionHubName
5) type
6) TEXT
7) WEIGHT
8) "1"
18) 1) identifier
2) vin
3) attribute
4) vin
5) type
6) TEXT
7) WEIGHT
8) "1"
19) 1) identifier
2) isArchived
3) attribute
4) isArchived
5) type
6) NUMERIC
20) 1) identifier
2) hasEvents
3) attribute
4) hasEvents
5) type
6) NUMERIC
9) num_docs
10) "0"
11) max_doc_id
12) "0"
13) num_terms
14) "0"
15) num_records
16) "0"
17) inverted_sz_mb
18) "0"
19) total_inverted_index_blocks
20) "0"
21) offset_vectors_sz_mb
22) "0"
23) doc_table_size_mb
24) "0"
25) sortable_values_size_mb
26) "0"
27) key_table_size_mb
28) "0"
29) records_per_doc_avg
30) "-nan"
31) bytes_per_record_avg
32) "-nan"
33) offsets_per_term_avg
34) "-nan"
35) offset_bits_per_record_avg
36) "-nan"
37) hash_indexing_failures
38) "0"
39) indexing
40) "0"
41) percent_indexed
42) "1"
43) gc_stats
44) 1) bytes_collected
2) "0"
3) total_ms_run
4) "0"
5) total_cycles
6) "0"
7) average_cycle_time_ms
8) "-nan"
9) last_run_time_ms
10) "0"
11) gc_numeric_trees_missed
12) "0"
13) gc_blocks_denied
14) "0"
45) cursor_stats
46) 1) global_idle
2) (integer) 0
3) global_total
4) (integer) 0
5) index_capacity
6) (integer) 128
7) index_total
8) (integer) 0
Hi,
I have been using the redislabs/redisearch:2.2.6 Docker image and it constantly crashes on my M1 MBP due to what appears to be a qemu crash, as the final line printed is
qemu: uncaught target signal 11 (Segmentation fault) - core dumped.I believe the easiest fix is to avoid relying on
qemu. Does RediSearch support ARM? If so, a similar approach to the mainredisimage on DockerHub could be used, offering an ARM version of theredislabs/redisearchimages.If that's not possible...any other ideas? 🙂
Thanks!
Here's the full crash logs: