eygle.com   eygle.com
eygle.com eygle
eygle.com  
 
Digest Net: July 2009 Archives

July 2009 Archives

原文链接: http://www-01.ibm.com/support/docview.wss?uid=csc179c2d650f71a939248256df800234bb9

内容提要:

Oracle 9i RAC (Real Application Cluster) 提供比单一实例更好的可用性和可扩展性,当前用户越来越多的开始采用RAC 的系统,用户在传统单一实例上的监视和调整系统CPU ,内存和硬盘的技能和经验,通常在RAC 环境中同样适用。然而在RAC 环境中有更多需要用户考虑的问题。

Oracle 9i RAC
多节点的结构引入了一个新的硬件模块 -- RAC 节点间的互联网络,用于协调各个节点的运行,包括全局锁(global locking) ,队列(enqueue) 和缓存管理(buffer cache management)RAC 是一种较新的技术,对于节点间互联的方式和性能的资料还很少,本文将对此进行一些分析,这些分析基于IBM pSeries 服务器和用户的实际工作负载.


    说明:



    1. RAC 互联配置
    IBM pSeries 环境下RAC 支持以下的互联选项,基于UDP 协议的100Mbps 或千兆的以太网,基于IBM 专利技术的SP SwitchSP Switch 2 。大多是RAC 的环境使用千兆以太网,因为千兆以太网能够在相对低的成本下,为大多数商业应用提供足够的带宽和可忍受的网络延迟。100Mbps 的以太网更适合于低负载的测试环境,而SP Swith 2 则适用于大型、高负载和对反应时间要求严格的复杂应用环境。

    通常RAC 的环境下,在公用网络的基础上,需要配置两条专用的网络用于节点间的互联,在HACMP/ES 资源的定义中,这两条专用的网络应该被定义为"private" 。在实例启动的过程中,RAC 会自动识别和使用这两条专用的网络,并且如果存在公用"public" 的网络,RAC 会再识别一条公用网络。当RAC 识别到多条网络时,RAC 会使用TNFF (Transparent Network Failvoer Failback) 功能,在TNFF 下所有的节点间通信都通过第一条专用的网络进行,第二条( 或第三条等) 作为在第一条专用的网络失效后的备份。



    CLUSTER_INTERCONNECTS 是在Oracle RAC 中的一个可选的初始化(init.ora) 参数。此参数可以指定使用哪一条网络用于节点间互联通信,如果指定多条网络,RAC 会在这些网络上自动进行负载均衡。然而,当CLUSTER_INTERCONNECTS 设置时,TNFF 不起作用,这将降低RAC 的可用性,任何一条节点间互联网络的失效,都会造成RAC 一个或多个节点的失效。

    AIX 环境中Oracle 数据库在单一实例下的性能调整方法(: 异步I/OVMM)Oracle RAC 环境仍然有效。但在Oracle RAC 环境下,需要考虑其他一些问题。RAC 采用UDP 协议进行节点间的互联通信,因此与UDP 有关的一些参数需要调整。建议udp_sendspace 的起始值为db_block_size * db_file_multiblock_read_countudp_recvspace 设为udp_sendspace4 倍,上限为1048576 。如果发生socket 缓存溢出( 可通过 netstat -s | grep "socket buffer overflows" 命令察看) udp_recvspace 参数值需要增加。

    Oracle STATSPACK 报告包含很多对于节点间互联性能的信息。首先应该查看的是"Top 5 Timed Events ",在RAC 的环境中,"global cache cr request "通常会出现在这里,如果这个事件(event) 在整个"Total Elapsed Time "中只占很小的比例 ( 如下例所示) 表示RAC 中节点间通信工作正常,否则,如果占的比例较大,表示节点间通信有问题。


    "Cluster Statistics" 部分包含了很多关于节点间通信性能的信息,如Global Cache Service (GCS) 的平均响应时间 (average response times) 尤其是关于getreveive 相关的事件。下面所示的是RACSwitch 2 环境下的数据,其带宽和网络延迟都大大好于千兆以太网。





    小结:
    对于Oracle RAC 来说,节点间通信的性能是需要特殊考虑的。节点间互联的网络提供"global cache coherency""global locking" 和其他RAC 管理的功能。工业标准的千兆以太网为大都数基于RAC 商业应用提供令人满意的性能,如果对于性能有更高的要求就需要选用IBMSP Switch2

IBM AIX svmon 简介之一

原文链接: http://www-01.ibm.com/support/docview.wss?uid=csc1ef3e1dda91b04aa248256da4004c60fb

svmon命令是虚存的的监视命令,svmon可用于确定某个程序、用户、内存段使用实存或虚存的情况。它事实上调用的是svmon_back命令,在使用svmon命令之前,必须确定svmon_back命令可用,该命令位置为 /usr/lib/perf/svmon_back
svmon运行于前台,就象一个普通的用户进程一样,因为它在运行过程中可被中断,所以,它无法完全真正地成为内存使用情况的快照。所以,在非常繁忙的系 统中,svmon收集的数据和真实的数据有所差距,在svmon进程搜集的过程中,VMM(虚存管理器)可能已经发生改动了。
因为svmon使用的全是VMM中的数据,而VMM对内存的视图是基于内存段的,所以,理解svmon的输出,必须先理解段的概念。
段(segment)是一组页的合集,每个段为256M,而每页为4KB字节的虚存,每帧为4KB字节的实存,每个段可同时被多个进程使用,每个段属于以下五种类型其中的一种:
persistent:存放JFS文件或目录
working:进程数据区域和共享内存段
client:用于实现虚拟文件系统如NFS,CD-ROM文件系统和JFS2
mapping:用于实现文件和内存之间的映射关系
real memory mapping:用于对I/O空间的访问
注意,在段的描述中,如果paging space使用的节中如果有一横(-),表明该段未使用交换区,work段可能使用交换区,但persistent段和client段不会使用交换区。
下面举例说明使用命令可做的一些工作:
1、# svmon -uP -t 3|grep -p Pid|grep '^.*[0-9] '
可将使用实存最多的三个进程标出
5428 X 4681 1584 2656 9156 N N
16274 bin 4594 1588 2273 8824 N Y
6458 dtgreet 4660 1580 2144 8712 N N
输出的格式顺序为 Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
可以计算出X程序所使用的实存为4681×4096=18763776,约为18MB

2、# svmon -gP -t 3|grep -p Pid|grep '^.*[0-9] '
可将使用交换区最多的三个进程标出,
5428 X 4681 1584 2656 9156 N N
16274 bin 4594 1588 2273 8824 N Y
6458 dtgreet 4660 1580 2144 8712 N N
第一个程序X所使用的交换区大小约为 2566×4096 =10510336 字节,大约为10MB空间

3、# svmon -S -t 3 -i 3
每隔三秒显示使用最多的段
Vsid Esid Type Description Inuse Pin Pgsp Virtual
4f08 -    clnt 37505 0 - -
11e1 -    clnt 33623 0 - -
8811 -    work kernel pinned heap 12637 6547 8091 19397
可见,Vsid为4f08的段使用最多

4、svmon -pP 22674
看PID为22674的进程所使用的为那些文件
Pid Command nuse Pin Pgsp Virtual 64-bit Mthrd
22674 java 29333 1611 2756 32404 N Y

Vsid Esid Type Description Inuse Pin Pgsp Virtual
0 0 work kernel seg 2979 1593 1659 4561
a056 - work 43 16  3   46
1e03 2 work process private 77 2   17  93
1080 - pers /dev/hd2:69742 1 0   -   -
f8bd f work shared library data 84 0   11  99
60ee 8 work shmat/mmap 0 0   0   0
70ec - pers /dev/hd2:69836 1 0   -   -
再利用ncheck命令,用户可自己建立脚本将device:inode信息抽取出来,如从上述的信息中,我们可通过ncheck得到输出:
/usr/java130/jre/lib/rt.jar
/usr/java130/jre/lib/fonts/LucidaSansRegular.ttf
/usr/java130/jre/lib/ext/indicim.jar
/usr/java130/jre/lib/ext/ibmjcaprovider.jar
/usr/java130/jre/lib/fonts/LucidaSansDemiBold.ttf
/usr/java130/jre/bin/java
脚本示例如下:
# expand -4 files.sh|nl
1 grep -p Vsid $1|
2 awk 'NR>1&&$0!~/^$/&&$4~/\/dev/{
3 l=substr($4,1,index($4,":")-1)
4 i=substr($4,index($4,":")+1)
5 if (l~/^\//)
6 print l,i
7 else {
8 print substr(l,index(l,",")+1),i
9 }
10 }'|
11 while read lv inode;do
12 fs=$(lsfs -c $lv 2>/dev/null|awk -F: 'NR>1{print $1}')
13 ncheck -i $inode $lv|awk '!/:$/{print lv $2}' lv=$fs
14 done


netstat -p protocol  原文出处

netstat -p protocol 显示了有关为 protocol 变量所指定的值(udptcpipicmp)的统计信息,该变量可以是协议的通用名称,也可以是其别名。

/etc/protocols 文件中列示了一些协议名称和它们的代名。一个空响应表明,没有要报告的数据。如果没有统计程序,那么协议参量指定值的程序报告就是不可知的。

下面的示例显示的是 ip 协议的输出:
# netstat -p ip
ip:
45775 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled ok
45721 packets for this host
51 packets for unknown/unsupported protocol
0 packets forwarded
4 packets not forwardable
0 redirects sent
33877 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 IP Multicast packets dropped due to no receiver
0 successful path MTU discovery cycles
1 path MTU rediscovery cycle attempted
3 path MTU discovery no-response estimates
3 path MTU discovery response timeouts
1 path MTU discovery decrease detected
8 path MTU discovery packets sent
0 path MTU discovery memory allocation failures
0 ipintrq overflows 0 with illegal source
0 packets processed by threads
0 packets dropped by threads
0 packets dropped due to the full socket receive buffer
0 dead gateway detection packets sent
0 dead gateway detection packet allocation failures
0 dead gateway detection gateway allocation failures

突出显示的字段描述如下:

  • Total Packets Received

    接收到的 IP 数据报总数。

  • Bad Header Checksum or Fragments Dropped

    如果输出表明无效报头校验和删除段是由于重复或超出空间造成的,这就表明网络传输信息包出现谬误或是设备驱动程序接收信息包的队列没有足够大。

  • Fragments Received

    收到的段总数。

  • Dropped after Timeout

    如果超时后删除的段为非零,那么 ip 段的计数时间在所有的数据报段到达之前就会因为网络繁忙而终止。为避免此情况,可使用 no 命令来增大 ipfragttl 网络参数的值。另一个原因可能是 mbuf 的不足造成的,这就要增加 thewall 的参数值。

  • Packets Sent from this Host

    由这个系统创建并发送出去的 IP 数据报数目。这个计数不包括转发的数据报(由流量转发)。

  • Fragments Created

    发送 IP 数据报时系统中创建的段的数目。

查看 IP 的统计信息时,参阅一下收到的信息包收到的分段的比率。对于小的 MTU 网络有一个准则,如果有 10% 或者更多的信息包进行了分段,那么您就应该进一步调查以确定其原因。如果有很大数量的分段,那表明远程主机 IP 层上的协议正在向 IP 传输比接口的 MTU 值要大的数据。网络路径中的网关或路由器可能也有比网络中其他节点小得多的 MTU 值。对于发送的信息包创建的段这也同样适用。

分段会导致 CPU 的额外负载,所以确定它的起因很重要。要知道一些应用程序本身就能够导致分段。比如,一个发送小数量数据的应用程序就能够导致出现分段。然而,如果您知道 应用程序正在发送大量的数据,同时仍然出现分段,就需要确定它的起因。然而,如果您知道应用程序正在发送大量的数据,同时仍然出现分段,就需要确定它的起 因。可能是因为使用的 MTU 大小不是系统中所配置的 MTU 大小。

下面的示例显示的是 udp 协议的输出:
# netstat -p udp
udp:
11623 datagrams received
0 incomplete headers
0 bad data length fields
0 bad checksums
620 dropped due to no socket
10989 broadcast/multicast datagrams dropped due to no socket
0 socket buffer overflows
14 delivered
12 datagrams output

下面是重要的统计信息:

  • Bad Checksums

    无效校验和可能是由于硬件板卡或是电缆故障造成的。

  • Dropped Due to No Socket

    那些没有打开端口的套接字所接收到的 UDP 数据报总数。因而,肯定会发送 ICMP 目标地址无法到达 - 端口无法到达的信息。但是如果收到的 UDP 数据报是广播数据报,就不会产生 ICMP 错误。如果这个值较高,就需要检查应用程序如何 如何处理套接字的。

  • Socket Buffer Overflows

    Socket Buffer Overflows(套接字缓冲区溢出)可能是由于发送和接收 UDP 套接字不足、nfsd 守护程序过少,或者是 nfs_socketsizeudp_recvspacesb_max 值过小而造成。

如果 netstat -p udp 命令表明套接字溢出,那么可能需要增加服务器上 nfsd 守护程序的数量。首先,检查受影响系统的 CPU 或 I/O 饱和度,然后使用 no -a 命令验证其他通信层的建议设置。如果系统处于饱和状态,那么您必须降低它的负载或是增加资源。

下面的示例显示的是 tcp 协议的输出:
 # netstat -p tcp
tcp:
576 packets sent
512 data packets (62323 bytes)
0 data packets (0 bytes) retransmitted
55 ack-only packets (28 delayed)
0 URG only packets
0 window probe packets
0 window update packets
9 control packets
0 large sends
0 bytes sent using largesend
0 bytes is the biggest largesend
719 packets received
504 acks (for 62334 bytes)
19 duplicate acks
0 acks for unsent data
449 packets (4291 bytes) received in-sequence
8 completely duplicate packets (8 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
5 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
2 window update packets
0 packets received after close
0 packets with bad hardware assisted checksum
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 discarded by listeners
0 discarded due to listener's queue full
71 ack packet headers correctly predicted
172 data packet headers correctly predicted
6 connection requests
8 connection accepts
14 connections established (including accepts)
6 connections closed (including 0 drops)
0 connections with ECN capability
0 times responded to ECN
0 embryonic connections dropped
504 segments updated rtt (of 505 attempts)
0 segments with congestion window reduced bit set
0 segments with congestion experienced bit set
0 resends due to path MTU discovery
0 path MTU discovery terminations due to retransmits
0 retransmit timeouts
0 connections dropped by rexmit timeout
0 fast retransmits
0 when congestion window less than 4 segments
0 newreno retransmits
0 times avoided false fast retransmits
0 persist timeouts
0 connections dropped due to persist timeout
16 keepalive timeouts
16 keepalive probes sent
0 connections dropped by keepalive
0 times SACK blocks array is extended
0 times SACK holes array is extended
0 packets dropped due to memory allocation failure
0 connections in timewait reused
0 delayed ACKs for SYN
0 delayed ACKs for FIN
0 send_and_disconnects 0 spliced connections
0 spliced connections closed
0 spliced connections reset
0 spliced connections timeout
0 spliced connections persist timeout
0 spliced connections keepalive timeout

下面是重要的统计信息:

  • Packets Sent
  • Data Packets
  • Data Packets Retransmitted
  • Packets Received
  • Completely Duplicate Packets
  • Retransmit Timeouts

对于 TCP 统计信息,比较发送的信息包数和重发的信息包数。如果重发的信息包数大于总发送信息包量的 10-15%,TCP 就会出现超时,这表明网络流量负载很大,在超时之前不能返回应答信号(ACK)。接收的网节点的瓶颈或是一般的网络故障也会导致 TCP 重发,这会增大网络流量,给网络性能带来了进一步的问题。

同样,需要比较接收到的信息包量和完整复制的信息包量。如果在发送网节点上的 TCP 在从接收节点收到 ACK 信号之前就已经超时,它会重发这个信息包。当接收节点最终接收到所有重发的信息包时会进行复制。如果复制信息包的数量超出了 10-15%,那么这个问题可能还是由于网络流量过大或是接收节点的瓶颈问题所造成的。复制信息包会增加 网络流量。

如果 TCP 发出一个信息包但没有按时接收到 ACK 信号,就会生成重发超时的一个量。然后它会重新发送信息包。对于任何后续重发,此值都会递增。这些持续的重发操作使得 CPU 的利用率更高,而且如果接收节点没有收到信息包,它最终会被删除掉。


原文链接 http://www.douban.com/group/topic/3761032/

1、某一集说某个村子每天半夜三更都有怪叫声,把全村人吵醒,大家都不敢出去看,战战兢兢地失眠到天亮。采访了一大堆上了岁数的村民,传说这里出没野兽,每天夜里到村子作怪,闹得人心惶惶......音乐配的那叫一个恐怖!还T M D分上下两集渲染!到最后竟然说那是村里一个胖子睡觉打呼噜!T N N D这胖子是金刚罗汉转世,还是帕瓦罗蒂的私生子?!打个呼噜能把一个村子的人吓醒?!K!我想砸电视!
  
2、还有一集说是一户人家老是发现自家客厅地上的瓷砖缝里会渗出像血一样的鲜红色液体,弄得到处都是,全村的人都不知道是怎么回事,猜会不会原来这块地是坟地啊什么的,然后又请了N多专家,研究他们家的地理位置地形条件,得出的结论都是依科学不可能发生地下矿物质倒渗这种情况发生......所以,最后的结论就是:液体是这家人家为了出名自己洒上去的!
  

我"咣垱"!一下倒地!
  
3、还有一期是说,挂了好几年的牛皮鼓忽然自己长出了牛毛!这件事在当地是蛮有名的件事,节目采访了那么多人,研究从厦大弄到了中央,都没有人说出个 所以然来,最后没办法了,硬栽赃人家做鼓的人不专业,毛没有刮干净,当初牛毛没刮干净?我晕。。。这不是怀疑做鼓人的专业水平吗?呵呵!
  

以这样的结论打发我,到底是看不起我的智商还是编导智商让人看不起!


4、还有一期说峨眉山的一个古寺,地处森林深处,但屋顶上从来没有一片树叶。就这么个事儿,经过漫长,深沉,全方位,多角度的分析,采访了寺中实习的和尚,游客,保安,居士,文物管理局局长,以及他的姑妈的二姐的堂妹的邻居家的一条狗,最后得出结论----是风吹走的。
  

我TMD当时就想跳楼!N N个熊,太伤我自尊了!
  
  5、刚看了一期,一对老人家的电灯晚上莫名其妙老是自己亮,结果大家都说他们家闹鬼,那对老人还居然病倒了。这其中还请了很牛比的大学生来也无法解 释,最后村里检修电路,说是开关的螺丝松了,紧紧就好了。 ~~~~~~我看完以为这是智障频道的节目,关键是TMD的居然还耐心看完了!
  
  6、还有那集《谁在背我飞行》,一开始那气愤渲染的那叫一个神秘啊。说30年前一农民前一天晚上10点还在河北交通闭塞的农村,第二天一早 5、6点醒来发现自己在南京了,自己不知怎么回事,同样的情况又发生了第二次,只不过到一醒发现自己到上海了。家里还被那两人留了名"山东高登民、高延津"。第三次被两人背着飞行了好几个城市。大概就这么个过程吧,节目弄得又是调查又是取证的,人证物证到处找。太TM神秘了,弄得我那个夜不能睡,日不能饭的啊!那叫一个相思啊!
  

结果最后来了几个鸟专家,硬说人家老实八交的农民是梦游去的南京,上海等地。看到这里,我当场晕了好一会,TM梦游做车难道不用买车票吗?难不成那年头全国人民都在梦游?不过想想倒也是,那时候可不是TM全国梦游吗?
  

后来,鸟专家又说人农民患了颠痫一切全都是幻觉,什么核磁共振,CT什么的追着人农民给人检查,拿人脑袋不当脑袋,结果检查结果没病,人家脑袋蛮正常。那鸟专家一看,又说了,那你就是得了偏执,这种病是检查不出来的!我当是就又晕了半天!N N 个 熊,T M到底谁得了偏执?人家没病你偏说人家有病,没有检查结果,创造检查结果也要说人家有病,到底谁才象得了偏执地?

7.最近的一期讲老人自燃的,老人身上的棉衣乃至他摸过的物体都会自燃,结果好奇心大增,看到最后, 我靠!是老头的外孙女点燃的,MD,这和科学有个屁关系。最后还引出几个儿女不孝这个话题,应该归到"家庭"里才对嘛!
    
  8、一个孩子经常僵尸附体。做出各种怪动作。比如翻白眼,咬人,胳膊伸直双腿向前跳,还有要喝血,想咬人。

  镜头昏暗,并且采访了N多村民,大家都表现的很害怕。
  

后来还搞了一个教授专门来调查,调查不出来。教授又把小孩子拖到华西医科大学的医院去检查,结论是身体健康。
  

最后,是带那个小孩子去看心理医生。医生问了几个呆问题,得出了结论,是因为小孩子想吸引家人的注意。因为他爸爸平时不太关心他。结果他装僵尸以后,他爸爸就很关心他,带他看医生。


9、一期讲一家没人住的老房子晚上发光,里面有张床像有人睡过,搞得神乎其神~~最后答案是发光是反射对面人家发出来的光,床的解释是一张是10年没人睡,一张是2年没人睡,结果被他一搞就成了干净一点的就有人睡了..当场晕厥(幸好我当时在床上)
    
  10、上次有个不怕电的,手拿220v的电线一点事都没有。最后送到北京某专家处一鉴定,说是该男老茧厚,所以不怕电。我看全中国7亿农民里至少得有5亿不怕电了
  
  11、水怪啊?水怪那几期呢,是这么忽悠人的,那个什么天池水怪,是三样东西。分别是水獭,乌龟,。。。第三样东西叫我吐血,居然是朝鲜人开的汽艇!
  
  12、最近看了期,是说共租一房的两个女孩,一到夜里就发现屋里不正常,查过去查过来,居然是那两个女孩的电脑中了木马。哈哈哈


13、还有孩子被鬼附身变左宗堂那一集也是解释的不伦不类,人家小孩子就不知道左宗堂是谁,可是把啥都说的轻轻楚楚的,不知道他们最后胡乱解释的啥。小孩僵尸附体时嘴里还念叨古文这个最后也没解释。

  14、有幸看过一集说是有个人死了N次都活过来了。。。最后结论是死的时候是发病(癫痫)。。。为什么能活过来呢。。是因为乡村里的赤脚医生每次在他假死时都偷偷给他输液。。。
  
  15、2006年9月,福建省华安县草板村一户普通的村民家发生了一件非常奇怪的事儿。在深夜,一声巨响,一个不明物体从天而降,撞断树枝,砸穿屋顶,深陷地面,在地里砸出了十几厘米深的坑。而且掉落下来的时候温度很高,摸起来还特别烫手,村民议论纷纷,有人说是陨石,有人说是飞机的零件,还有人传闻是ufo残片,更有甚者竟然说这个东西好像是外星人的尿壶,到底是天外来物还是另有原因?这个不明物体究竟是什么,它怎么会掉落在这儿呢?《走近科学》为您揭开谜底。   
  

经过故弄玄虚之后最后告诉你是TM一私自罐氢气的小贩,不小心把罐弄爆炸,碎片落下来了!我狂晕


16、记不大清楚是不是这栏节目,反正是CCTV10的,说的是一个老农用电笔测出房间带电,后来发展到地面带电,最后干脆,我C,空气带电,220V还多,当然出现这种现象人没事。有点文化的人,或者有点常识的人都知道,肯定是电笔出问题,我是看笑话一样看完节目的,真是服了。
  
  17、我看的那期更吊,第一天预告的时候瞎掉我们的胃口,一个女的(忘了哪里的)五年不吃饭,居然身体健康,他家人也承认她五年来的确没有进食,只喝水,我兴趣极度膨胀,还分两集,最后把这女的和他老公弄到省医院检查,最后经过N多专家检查得出一结论,这女的得了臆病,就是幻想症,强迫症之类的,事实上还是吃了东西的,只是吃得少,我真是昏了,她一个人有臆症,他朝夕相处的家人还信誓旦旦的证明,难道她一家人都有狂想症?他一家人又不是想出名,又没有得利,解释来解释去真是难已让人信服!后来还看了一期,一个贵州还是云南那边的少数民族女初中生鬼上身,在课堂上昏倒,醒来后突然家乡话也不会说了,亲人也不认识了,说自己是福建那边来的,还说福建那边的话,最后的结论是这个女孩学习压力大,得了臆病,真 他 吗恶心,以后干脆别叫走进科学了,就叫走进臆病得了,我当时气得噢, 粑 粑 主持人你能相信这个结论吗,出来混饭吃也得花点本钱,随便三两句就想打发咱这些观众,真不知道CCTV办这个节目的初衷是什么,你每次的结论能把自己说服了再来说服观众。


18、谁背我飞行那个外星人系列的还有一集,说村子里面看见飞碟,村里面比较有文化的一个人研究了多年,收集了n多证据,专家跑出了分析半天搞不清楚到底是为什么。难道真的有飞碟和外星人。结果发现那个人其实是个精神病患者,而且村子里面都知道。


  所谓的调查非常草率,所谓的结论非常荒唐,每次都故弄玄虚、哗众取宠,拍的像鬼片,最后得出一个莫名其妙的结论


19、还有一期节目,说一农村女子身上常常出现字,然后进行了猜测:是鬼附体?于是记者跟踪观察,还去了医院......一个沙哑的声音故弄玄虚地解说着....看不下去了。白痴也知道是自己划的。
这倒显露了我们的科普态度甚至是教育民众的态度:是引领进步,还是愚弄、听之任之。


20、《午夜木乃伊走路》  


大概讲一个木乃伊展览馆到了晚上就会听到有人在走廊上走路的声音......但是仔细看了却又没有人!!!于是恐怖的木乃伊夜半走路的传言便传开了......于是许多学者介入调查发现..................   
其实是木地板日热涨夜冷缩造成的声响......    
 

21、《人狼嚎》  

大致讲一个人他每天到了半夜都会像狼一样对着月亮狼嚎......吓死了四周邻居街坊......于是又有许多学者介入调查发现........................   其实是这个人患有癫痫......平常又喜欢看动物世界......结果晚上发神经的时候就模仿印象中最深刻的狼状......     

22、《吐血狂人》

(这个最经典......经典的可以让大家都去吐血好了)  大致讲一个男人他一运气功,就可以从嘴巴里面吐出血来!!而且他全身都可以出血,只要用嘴巴吸一下皮肤,皮肤上就会有一堆血,而且好起来极快,只要把血擦掉皮肤上就不会留下任何痕迹!!于是又有很多专家学者介入调查..................发现..................  其实这个人是牙龈出血..................(真是有够了!!)    


我想说的就是:专家学者们辛苦了!!cctv辛苦了!

23、其他讨论观点

那个走进科学也是的。 科他M的学,说是有不明飞行物,调查后得知那是飞蛾。
还有神秘鬼火,结果是他们家地下天然气泄露。
就是有一期讲的是佛手公主,玄的阿,其实就是遗传性的手脚残疾。真是,前面玄的阿。
牙龈出血那个,真是一个奇冷的笑话~~~  


还看过中央10套的一个节目,说小孩爬上祭奠塔看见里面有火光,然后神秘兮兮的讲到底,切~~~是当地居民在里面烧垃圾。

大家还有没有看到中央10套讲N多湖里都有水怪,讲来讲去,结果就是某种大鱼----还是疑似,这些人,鱼都不认识了还好意思说。


我还看过一期! 什么分身大盗的:就说那人明明被关监狱里面了,别处犯案之后目击证人还说就是他。反正可神呢!偶就看啊看,最终结局是双胞胎......

吼吼,上次和姐妹饭饭,说起"走近科学",喷饭不止:


有一集是什么山顶的灯光,怀疑是外星人......我一看就知道了,肯定是旁边酒店的激光灯,果不其然......

我也看了一次,说一头小公牛下了一个怪蛋,又是X光又是找的科学院......原来是饲料缺磷导致小牛患上异食癖,总喜欢舔自己的毛吃,结果毛在体内积攒多了就被拉了出来,圆圆的毛球像个蛋......

今后看完走近科学的观众,会不会冻死唻?......吼吼


前几天王小峰同学在不准联想上又说到一个:一个女娃娃,放学后没有按时回家,大家等啊等,等啊等,等不到,就找啊找,找啊找。。。。。女娃娃消失了,,,,科学开始了。。。。。。其实这个女娃娃在半路上叭叽掉进地缝里,一直爬啊爬,爬啊爬,最后爬上来了,于是回家了,故事完了,科学也完了。

Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from July 2009 listed from newest to oldest.

May 2009 is the previous archive.

August 2009 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.