If Excel is a problem to have an idea, you can use the variableMetadata file to get the information in another way. Indeed, in this file you will find columns (one per class you consider in the extraction process, or a single one if no class was specified) that counts the number of samples in which each ion was found. Thus, with a simple trick of substraction (number of samples - content of the column), you can have the information of the number of NA per ion.
Here is an example:
Here I used 3 classes for extraction (QC, blk and sample) so I have 3 corresponding columns generated in the variableMetadata. I have respectively 3, 3 and 6 samples in these groups. In Excel, I get have the number of NA for each ion and for each group with the calculation given in columns N, O and P. The total number per ion is thus the sum of these 3 "green" columns.
This can be easier than the CTRL+F for huge dataMatrix in Excel. You can also add some metrics as the % of NA based on these columns. Please note that you can also use Galaxy to have this computed by using the Intensity_check Galaxy module, available in the "Quality processing all" section in the tool panel, with a graphical representation as complement.
Again, I do not know your project so my comment may not match your study design, but if you have that many NA in your data with good reason to keep all these ions in your dataset, it may be wise not to perform fillChromPeaks right away but first analyse your data with a "NA / not NA" point of view to have a better idea of what your are dealing with. Then, if your conclusion is that it is relevant to analyse all these ions in a more "quantitative" way, then consider trying to perform the fillChromPeaks. Trying to fill NA in a dataset where NA is the majority value is always risky and should be done with huge care.
Anyway, still waiting for a Galaxy guy to give us some light on what is possible regarding the runtime limit