The input data has suspect spatial reference properties. In particular, the SR XYResolution has been modified to be much smaller than the default. This can cause a number of problems during the processing and storage of data. It is recommended only default properties be used. For more information, refer to the following documentation:
https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-and-hair/?srsltid=AfmBOoq-6tYRDRCoxC2fShWxvxz8TaVJ2OOdWMJWXstPSUOr552uoCrn
https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/detect-and-repair-invalid-spatial-references.htm
https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/the-properties-of-a-spatial-reference.htm
https://pro.arcgis.com/en/pro-app/3.0/help/data/geodatabases/overview/feature-class-basics.htm#GUID-76CEEA65-4E1D-4DF0-A085-2D1A736EC6F5
https://support.esri.com/en-us/technical-paper/understanding-coordinate-management-in-the-geodatabase-1301
https://pro.arcgis.com/en/pro-app/latest/tool-reference/appendices/spatial-reference-and-geoprocessing.htm
Note: The two inputs do not share the same spatial reference properties, and both sets of the spatial reference properties are suspects. The input feature classes spatial reference properties are used to project the erase feature class on the fly. This is effectively projecting an already 'bad' spatial reference to another 'bad' spatial reference. This is not a good idea for trying to generate meaningful results. Also, repairing these inputs as per the blog post provided in the workaround and then projecting the two repaired inputs to the same, good spatial reference and then running the tool may also allow for performance gains.
解决办法
To avoid possible issues due to the data's bad spatial reference properties, the data's spatial reference should be repaired as per the following blog: https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-and-hair/?srsltid=AfmBOoq-6tYRDRCoxC2fShWxvxz8TaVJ2OOdWMJWXstPSUOr552uoCrn
Although it is stated there is plenty of physical memory at the time of failure, there is a bug in Windows that Microsoft has released a workaround for that has helped many users get past similar failures. Please apply the workaround. Refer to the following documentation for the workaround: https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/slow-page-file-growth-memory-allocation-errors. When applying the workaround, the recommended size of the page file must be set to 64 GB.