梳理M1芯片Mac mini 执行 pod install 失败Ruby直接崩

Python08

梳理M1芯片Mac mini 执行 pod install 失败Ruby直接崩,第1张

环境:2020款M1芯片Mac mini ,Xcode 13.3.1,Ruby为自带2.6.8

简述:

    刚开始安装时还按照正常逻辑安装cocoapods,执行pod install 时,报Ruby崩溃,让上报错误信息:

You may have encountered a buginthe Ruby interpreter or extension libraries.Bug reports are welcome.For details:https://www.ruby-lang.org/bugreport.html

最后几番折腾,知道是 ffi 相关包执行X86指令集,需要适配M1芯片架构,即arm64指令集

主要涉及Ruby版本,我系统版本Mac OS 12.3.1,ruby版本系统自带2.6.8,升级ruby会涉及其他软件包,gem等,皆升级到最新。

此时Ruby升级为3.0.0,再次安装pod,问题解决

详细步骤不再重复造轮子,引用下面这位作者文章,对我帮助很大,感谢:https://www.jianshu.com/p/a768181c1245

集成gitlab CI后,脚本执行pod install后出现两个问题:1.让注册当前Mac mini设备ID到profile文件。这是无需的,我们需要在 xcodebuild archive 时 添加 -destination 'generic/platform=iOS' 即可解决;2. 再次pod install时发现 Pods.xcodeproj 不能正常生成,报 can not open Pods.xcodeproj 错误,解决:在 ~/.profile 文件增加: export LANG=en_US.UTF-8

型号: MacBook Air (M1, 2020)

终端 直接运行,不需要勾选 Rosetta

rvm install ruby --head --verify-downloads 2

升级后的版本是 3.1.1p80

安装可能失败,大部分是网络问题,自行解决,执行下面的命令

gem install ffi

安装成功后输出以下日志

安装好以上的环境后,安装 CocoaPods 执行以下命令

sudo gem install cocoapods -n /usr/local/bin

输入密码,回车,等待安装

安装成功

1.解决常见问题

我们正在添加更多故障排除提示,因此请稍后再回来查看。 如果您要添加一些内容,请:

在https://github.com/elastic/logstash/issues创建问题,或

在https://github.com/elastic/logstash创建带有您建议的更改的请求请求。

还可以访问Logstash discussion forum。

1.1.安装与设定

1.1.1.临时目录无法访问

JRuby运行时的某些版本和某些插件中的库(例如,TCP输入中的Netty网络库)将可执行文件复制到temp目录。 在/ tmp挂载noexec时,这种情况会导致后续失败。

Sample error

[2018-03-25T12:23:01,149][ERROR][org.logstash.Logstash ]

java.lang.IllegalStateException: org.jruby.exceptions.RaiseException:

(LoadError) Could not load FFI Provider: (NotImplementedError) FFI not

available: java.lang.UnsatisfiedLinkError: /tmp/jffi5534463206038012403.so:

/tmp/jffi5534463206038012403.so: failed to map segment from shared object:

Operation not permitted

可能的解决方案

更改设置以使用exec挂载/ tmp。

使用jvm.options文件中的-Djava.io.tmpdir设置指定备用目录。

1.2.Logstash启动

1.2.1.非法的反射访问错误

使用Java 11运行Logstash会产生类似于以下警告:

WARNING: An illegal reflective access operation has occurred

WARNING: Illegal reflective access by org.jruby.util.SecurityHelper (file:/Users/chrisuser/logstash-6.7.0/logstash-core/lib/jars/jruby-complete-9.2.6.0.jar) to field java.lang.reflect.Field.modifiers

WARNING: Please consider reporting this to the maintainers of org.jruby.util.SecurityHelper

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

WARNING: All illegal access operations will be denied in a future release

这些错误似乎与JRuby的已知问题有关。

解决

尝试将这些值添加到jvm.options文件。

--add-opens=java.base/java.lang=ALL-UNNAMED

--add-opens=java.base/java.security=ALL-UNNAMED

--add-opens=java.base/java.util=ALL-UNNAMED

--add-opens=java.base/java.security.cert=ALL-UNNAMED

--add-opens=java.base/java.util.zip=ALL-UNNAMED

--add-opens=java.base/java.lang.reflect=ALL-UNNAMED

--add-opens=java.base/java.util.regex=ALL-UNNAMED

--add-opens=java.base/java.net=ALL-UNNAMED

--add-opens=java.base/java.io=ALL-UNNAMED

--add-opens=java.base/java.lang=ALL-UNNAMED

--add-opens=java.base/javax.crypto=ALL-UNNAMED

--add-opens=java.management/sun.management=ALL-UNNAMED

笔记:

这些设置允许Logstash在Java 11中启动而不会发出警告,但它们阻止Logstash在Java 8上启动。

此解决方法已通过简单的管道进行了测试。 如果您有经验可以分享,请在issue中发表评论。

1.3.数据提取

1.3.1.错误响应代码429

429消息指示应用程序正在忙于处理其他请求。 例如,Elasticsearch发送429代码以通知Logstash(或其他索引器)由于接收队列已满,批量失败。 Logstash将重试发送文档。

可能采取的行动

检查Elasticsearch以查看是否需要注意。

https://www.elastic.co/guide/en/elasticsearch/reference/7.4/cluster-stats.html

https://www.elastic.co/guide/en/elasticsearch/reference/7.4/es-monitoring.html

Sample error

[2018-08-21T20:05:36,111][INFO ][logstash.outputs.elasticsearch] retrying

failed action with response code: 429

({"type"=>"es_rejected_execution_exception", "reason"=>"rejected execution of

org.elasticsearch.transport.TransportService$7@85be457 on

EsThreadPoolExecutor[bulk, queue capacity = 200,

org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@538c9d8a[Running,

pool size = 16, active threads = 16, queued tasks = 200, completed tasks =

685]]"})

1.4.一般性能调优

有关常规性能调整的提示和准则,请参阅Performance Tuning。

1.5.常见的Kafka支持问题和解决方案

1.5.1.Kafka会话超时问题(输入端)

Symptoms

吞吐量问题和重复事件处理Logstash记录警告:

[2017-10-18T03:37:59,302][WARN][org.apache.kafka.clients.consumer.internals.ConsumerCoordinator]

Auto offset commit failed for group clap_tx1: Commit cannot be completed since

the group has already rebalanced and assigned the partitions to another member.

两次调用poll()之间的时间长于配置的时间

session.timeout.ms,通常意味着轮询循环在处理消息上花费了太多时间。 您可以通过增加会话超时或通过使用max.poll.records减小poll()中返回的批处理的最大大小来解决此问题。

[INFO][org.apache.kafka.clients.consumer.internals.ConsumerCoordinator] Revoking

previously assigned partitions [] for group log-ronline-node09

`[2018-01-29T14:54:06,485][INFO]`[org.apache.kafka.clients.consumer.internals.ConsumerCoordinator]

Setting newly assigned partitions [elk-pmbr-9] for group log-pmbr

Background

Kafka跟踪消费者群体(例如,多个Logstash实例)中的各个消费者,并尝试为每个消费者在他们正在使用的主题中提供一个或多个特定的数据分区。 为了实现这一点,Kafka跟踪使用者(Logstash Kafka输入线程)是否在其分配的分区上取得了进展,并重新分配了在指定时间范围内未取得进展的分区。

当Logstash向Kafka Broker请求的事件超出其在超时范围内无法处理的事件时,它将触发分区的重新分配。 分区的重新分配需要时间,并且可能导致事件的重复处理和严重的吞吐量问题。

Possible solutions

减少Logstash在一个请求中从Kafka Broker轮询的每个请求的记录数,

减少Kafka输入线程的数量,和/或

在Kafka Consumer配置中增加相关的超时。

Details

max_poll_records选项设置一个请求中要提取的记录数。 如果超过默认值500,请尝试减小它。

Consumer_threads选项设置输入线程的数量。 如果该值超过了logstash.yml文件中配置的管道工作程序的数量,则应该减少该值。 如果该值大于4,如果客户端有时间/资源,请尝试将其减小到4或更小。 尝试从1开始,然后从那里开始递增以找到最佳性能。

session_timeout_ms选项设置相关的超时。 将其设置为一个值,以确保max_poll_records中的事件数可以在该时限内安全地处理。

EXAMPLE

Pipeline throughput is `10k/s` and `max_poll_records` is set to 1k =>. The value

must be at least 100ms if `consumer_threads` is set to `1`. If it is set to a

higher value `n`, then the minimum session timeout increases proportionally to

`n * 100ms`.

实际上,该值必须设置为比理论值高得多,因为管道中输出和滤波器的行为遵循分布。 该值还应该大于您期望输出停止的最长时间。 默认设置为10s == 10000ms。 如果您遇到输出因负载或类似影响而可能停顿的周期性问题(例如Elasticsearch输出),则将该值显着提高到60s几乎没有什么不利之处。

从性能的角度来看,减小max_poll_records值优于增大超时值。 如果客户端的问题是由定期停止输出引起的,则增加超时是唯一的选择。 检查日志以获取停顿输出的证据,例如ES输出日志状态429。

1.5.2.大量的偏移提交(Kafka输入端)

Symptoms

Logstash的Kafka输入导致对偏移量主题的提交数量比预期的多得多。 通常,投诉还提到重复执行相同偏移量的冗余偏移量提交。

Solution

对于Kafka Broker版本0.10.2.1到1.0.x:问题是由Kafka中的错误引起的。 https://issues.apache.org/jira/browse/KAFKA-6362客户的最佳选择是将其Kafka Brokers升级到1.1版或更高版本。

对于较旧版本的Kafka或上述解决方案不能完全解决问题:可能是由于将poll_timeout_ms的值设置得相对于Kafka经纪人自己接收事件的速率而言太低(或者如果经纪人在两次接收之间周期性地闲置) 突发事件)。 在这种情况下,按比例增加为poll_timeout_ms设置的值会减少提交的偏移量。 例如,将其提高10倍将导致偏移提交减少10倍。

1.5.3.Kafka输入中的编解码器错误(仅在插件版本6.3.4之前)

Symptoms

Logstash Kafka输入会随机记录配置的编解码器中的错误和/或错误地读取事件(部分读取,多个事件之间的数据混合等)。

Log example: [2018-02-05T13:51:25,773][FATAL][logstash.runner ] An

unexpected error occurred! {:error=>#<TypeError: can't convert nil into String>,

:backtrace=>["org/jruby/RubyArray.java:1892:in `join'",

"org/jruby/RubyArray.java:1898:in `join'",

"/usr/share/logstash/logstash-core/lib/logstash/util/buftok.rb:87:in `extract'",

"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-codec-line-3.0.8/lib/logstash/codecs/line.rb:38:in

`decode'",

"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-kafka-5.1.11/lib/logstash/inputs/kafka.rb:241:in

`thread_runner'",

"file:/usr/share/logstash/vendor/jruby/lib/jruby.jar!/jruby/java/java_ext/java.lang.rb:12:in

`each'",

"/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-kafka-5.1.11/lib/logstash/inputs/kafka.rb:240:in

`thread_runner'"]}

Background

当在多个线程上运行(consumer_threads设置为>1)时,Kafka Input插件处理编解码器实例的方式存在一个错误。 https://github.com/logstash-plugins/logstash-input-kafka/issues/210

Solution

将Kafka Input插件升级到6.3.4或更高版本。

如果(且仅)不可能升级,请将consumer_threads设置为1。

1.5.4.Other issues